Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 10:39 05 May 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : Rogue data on MM2 COM port...

     Page 1 of 2    
Author Message
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 04:34am 03 Jul 2017
Copy link to clipboard 
Print this post

Hi there.


MM2 version 5.04.04

1) Com port closed - no rogue data.
2) OPEN com port, send some data. This is received OK.
3) CLOSE com port, rogue data starts being sent.

This is a MM connected to an HC-12, and at power-up, the HC-12 does not send any rogue data, and it is just fine till the first cycle, then as soon as you close the com port, the HC-12 starts sending rogue data across the link - which totally screws up the other end.

I am thinking I might be able to fix this by leaving the com port open(IE: don't close it), but one of the reasons for closing it, was to keep the buffer purged so I don't get this crud in the first place in the data-stream.

The HC-12 has on-board pull-ups, so I should not need any on my board as the HC-12 provides them for me.

COM1 on MM2, which is 5v tolerant. No resistors between HC-12 and MM2(directly connected)
Baud-rate is 1200, so very slow.

I will be putting the logic analyser on it tomorrow, but from experiments at the console, the data appears to just be garbage. Most of the bytes received into the buffer are non-printable characters, so it's almost like the white-noise garbage you get on a "Dumb" receiver before you sync it with the likes of 0101010101 kind of thing.

With my having completed one cycle, and running a simple code at the other end to print the com port buffer size to the console, I get the following output:




The zeros at the top are at power-up OF THE TRANSMITTING MM - so no problems till you send the first transmission - 10 bytes. After that, the buffer just keeps filling up with garbage. There are plenty more plain zeros above this screen shot, but I cropped them out as they are always zero till the first transmission cycle.

Can anyone else suggest anything I should try at this point?

EDIT: Here is the test alarm code that is doing this very odd com-port behaviour.



It is indeed possible, that the HC-12 I am using is crook or something, so I will be checking what is indeed coming out of the MM COM port on the logic analyser tomorrow - perhaps the HC-12 is unstable and is generating the problem internally? Anyone seen that before?Edited by Grogster 2017-07-04
Smoke makes things work. When the smoke gets out, it stops!
 
piclover
Senior Member

Joined: 14/06/2015
Location: France
Posts: 134
Posted: 07:10am 03 Jul 2017
Copy link to clipboard 
Print this post

What's happening if you configure COM1: input as a digital input after closing the serial port (e.g. SETPIN 22,DIN after the CLOSE #1) ?... It should stop buffering data to the serial buffer.

My hypothesis is that your HC-12 is picking up noise (or another close-by 433MHz transmitter) and keeps sending data to your MM.Edited by piclover 2017-07-04
 
CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985
Posted: 10:07am 03 Jul 2017
Copy link to clipboard 
Print this post

Hey Grogs...

I have seen HC12s pick up crap from nearby systems... can you try them on another channel?

I always have some "envelope" around my stuff so it is easy for both ends to discard garbage as i could never rely on a clean channel and every installation had to be customised. Now i don't bother and everything just uses channel 0.

Any noise is swamped by genuine HC12 chatter and I get zero corruption when the comms are used in anger. My range generally isn't extreme (nothing like the possible 1.2Km) but I have seen rubbish turning up. Here is the schema of my envelope, I can post some stripped-down code for you to test with if you are interested: (top tip, I broadcast the time regularly thus nodes do not require RTCs - I am so cheap!) I have networks using this and have T/RX hundreds of MB with no detected errors, even in known noisy areas (that actually drove the dev of this protocol). The actual working code employs a simple rolling encryption so the packets are not easily "sniffed"

Another tip is to put a 4K7+LED from VCC to the TX pin from the HC12 to see the data arrive. It functions as a nice "network busy" visual indicator and is a really good addition to fault finding.


Master is always address 0
Slaves are address 1 - 998
Broadcast is address 999

Master initiates all communication and slaves only ever respond to Master requests for interaction (STAT or POLL).
Most packets consist of a 4 character verb and then the payload.

All devices must be on the same "channel". It was explored that each slave might exist on its own channel but this was abandoned
early on because:

Separate channel: Pro
slave does not need to parse the addresses from the packet - if it hears the packet then it must be for that slave.
Con
Broadcast becomes impossible.
Device addresses limited to 127.
Cheap RxTx modules have no concept of channel.

Single channel: Pro
Slave address is encoded as part of the packet header with a theoretical maximum of 998 devices. Different channels
permit single master with multiple slave zones if required, thus giving < 128000 devices (but broadcast and use of
cheapie modules will be impacted).
Broadcast is simple - all devices hear the broadcast and pick the addresses from the packet as normal.
Can use cheapie 433MHz TxRx pairs with no onboard processing (see preamble).
Con
HC-12 module is more expensive


Command Source Details
-----------+-------+------------------------------------------
STAT: Master Master STATs address.
Slave MUST respond within 1.5 seconds and may send back data, thus a STAT contains an implicit POLL.
Nil response will result in the slave marked as not available in the status register (master will not POLL).
Slave must rep-y with ACK0 only - an INIT is pending on first discovery. If the Slave has more to say, it must wait for a poll
POLL: Master Master POLLs address.
Slave may respond but must do so within within 1.5 seconds if it has something to say but keeps quiet otherwise.

ACK0: Slave This is the terminating response to a STAT or POLL. This packet will cause the Master to accept the response and
move on to the next section of the cycle.
ACK1: Slave This is the response to a POLL only but signifies the slave has more to report. This packet will cause the
Master to accept the response and then immediately issue another POLL to the same slave. Multiple ACK1's may be
sent and the Master will continue to POLL and accept packets until receipt of ACK0 or a timeout occurs, at which
point the master will move on to the next section of the cycle. The slave must pause for 1.5 seconds between each
ACKx packet.
INIT: Master The slave must restart.
SAFE: Master The slave must go to its default/safe/power-up state.

Broadcasts: Any packet with destination address 999 is assumed to be a broadcast. Thus there is no specific broadcast verb.
Usually only the Master Broadcasts. No slaves may respond.

TIME: Master The payload is hh:mm:ss,dd/mm/yyyy All slaves synchronise their clocks to the payload.
INIT: Master The slave must restart.
SAFE: Master The slave must go to its default/safe/power-up state.
FIRE: Master The slave must go to its FIRE mode state.

Note: Slaves must never reply to broadcasts under any circumstances.


Slave must respond to STATs. The response (or lack of it) updates the internal status register for that slave. Slaves that do not
respond to a STAT will be skipped in the POLL cycle.

Master: STAT (nn)
Slave: Must reply with ACK0 (or ACK1 if there are multiple return packets) to the Master. The payload may be empty.

Master: POLL (nn)
Slave: May reply with ACK0 (or ACK1 if there are multiple payloads) to the Master. The payload may be empty but it is
recommended the slave not respond to a POLL if it has nothing to report. This reduces the cycle time and processing load


Packet format (master and slave):


[pp.pp.]STX<checksum>GS{ENCRYPT<dest address><src address><Payload>}ETX

the data between the GS and ETX is encrypted before transmission.
RC4 is a complex algorithm with a moderate data requirement (0.5K). A simpler encryption algoritm XORing a
variable length key is available if the simple nature of the slaves cannot support it i.e. simple PIC/Atmel chips

so a typical Tx from the master to device 05 looks like



Preamble When using cheap TxRx modules with no onboard processing, it is necessary to send a stream of 1's to the Tx so the Rx
can set it's levels before the actual data arrives. Because of this, some of those bits mat be lost so anything before
STX must be discarded. Chr FE has a large amount of "1" space and the trailing 0 ensures the levels are set on Rx devices
immediately before they are required to be accurate. A string of at least 2 FE chars is effective.
Using devices like HC-12 where there is onboard processing to assure data integrity, a preamble is not necessary as it is
taken care of by the radio module.

Preamble [FE FE ...]

Typical Packet structure
02 = STX, sync marker
CHK_HI ASCII Hex of checksum of packet between GS and ETX
CHK_LO
1D = GS group separator
[ 30 = attention device 005 in ascii
[ 30
[ 35
[ 30 = from the master 000 in ascii
[ 30
[ 30
[ [
[ 50 STAT
[ 49
[ 4E
[ 47
[ | or
[ 50 POLL
[ 4F
[ 4C
[ 4C
[ ]
[ any message here
03 = ETX, end of transmission

Any response must begin transmission in the next 1.5 seconds
Edited by CaptainBoing 2017-07-04
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 04:58pm 03 Jul 2017
Copy link to clipboard 
Print this post

Thanks for the replies.

Logic Analyser says that all that crud at the end are "Framing errors", most equal to zero.

This is with the logic analyser directly on the COM1 TX line and ground. The wanted data is there, but it is followed up with random garbage.

I will now isolate COM1:TXD and tap directly into THAT and see if I still get the rubbish, as that would mean it IS coming from the MM2 chip, and not the HC-12.

Will keep you all updated.
Smoke makes things work. When the smoke gets out, it stops!
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 05:05pm 03 Jul 2017
Copy link to clipboard 
Print this post

UPDATE:

MM2 is in the clear - no problems there when I send the data. It is PERFECT out of the MM2, and EXACTLY as it should be. Connect the HC-12 to the line, and you get the garbage.

With the MM2 feeding the logic analyser, but the HC-12 disconnected from COM1:TXD, there is no problem with either the serial output of the MM2, or the HC-12 - it does not send any rogue data. If I reconnect the COM1:TXD line to the HC-12, the problem resurfaces.

Bizzare....

I will now setup the code in the MM2 transmitter so that after a close, it makes the pin an output and sets it high. I might also try hacking a 4k7 pull-up to this line, although, I did not think it would be needed, as the HC-12 has it's own pullups.....


Smoke makes things work. When the smoke gets out, it stops!
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 05:39pm 03 Jul 2017
Copy link to clipboard 
Print this post

UPDATE:

OK, if I SETPIN 21,OFF before I open the com port, then after I close it, I SETPIN 21,DOUT:PIN(21)=1 to make it idle-high, this seems to be stopping all the rogue data in initial tests - so far.

The HC-12 still seems to be appending 0xFF(255) to the end of EVERY message, even though I have not asked for that, but so long as it keeps doing that, I can use THAT as my end of message byte rather then CR.

I am now going to connect to the logic analyser again and check what is coming out.
The experimentation continues.

Smoke makes things work. When the smoke gets out, it stops!
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 07:28pm 03 Jul 2017
Copy link to clipboard 
Print this post

UPDATE:

OK, I think we are making progress here.

I have added a 4k7 pull-up to 3v3 on the COM1:TXD line, and all the problems have vanished - for now.

I think that the reason it worked fine on the FIRST cycle through, was that at power-up, all I/O pins are set as INPUTS, but critically at this point, they are NOT left floating.

So, the first transmission cycle works, but then the code runs into the CLOSE command, and leaves the pin in a floating state, and the HC-12 is trying to react to this as data when it isn't.

The pull-up seems to have fixed this, and I have removed the SETPIN commands from the post above, and everything is working well now.

I'll keep my fingers crossed, but I expect that was why the first cycle worked - and was confusing the hell out of me as to WHY it worked OK once, but not more then that.
Smoke makes things work. When the smoke gets out, it stops!
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 07:57pm 03 Jul 2017
Copy link to clipboard 
Print this post

UPDATE:

Perhaps not....

Put it all back together with the 4k7 pull-up, and getting garbage again.
I think I might need to keep the before/after PIN config after all(SETPIN).

I guess the pin IS still technically floating following the CLOSE command, so even with the 4k7 pull-up, if it floats down this is enough to trip the HC-12 and it thinks it needs to respond.

The saga continues....
Smoke makes things work. When the smoke gets out, it stops!
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5913
Posted: 08:08pm 03 Jul 2017
Copy link to clipboard 
Print this post

The HC-12 datasheet refers to a "weak pull-up" on the Rx pin.
It looks like it is too weak in your case. You must be getting some cross-talk or leakage somewhere.

The micromite manual tells us that the serial port will indeed go to high Z:
  Quote  Serial ports can be closed with the CLOSE command. This will discard any characters waiting in the buffers,
free the memory used by the buffers, cancel the interrupt (if set) and set all pins used by the port to the not
configured state.


Setting the port to an output is a brute force way of keeping it under control but I am surprised that the internal pull-up in the HC-12 is not doing its job.


What voltage are you running the HC-12 on?

VK7JH
MMedit   MMBasic Help
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 09:10pm 03 Jul 2017
Copy link to clipboard 
Print this post

Hi Jim.

5v for the HC-12.

I think I will change the code to leave the com port open rather then close it.
I could also perhaps make use of the ChangePin Cfunction, and set a permanent pull-up on it. That would save me having to get more PCB's done for the sake of one resistor.

EDIT: I can't do that. The ChangePin Cfunction specifically says not to enable pullups on an output, which is what COM1:TXD is. I will leave the 4k7 external resistor in place for good luck, and just not close the port.

Yes, I too thought the internal pull-up would do it, but it must be a rather high-value pull-up. It could be 500k or 1M or something for all I know. I have not been able to find a schematic for the HC-12 as yet.Edited by Grogster 2017-07-05
Smoke makes things work. When the smoke gets out, it stops!
 
CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985
Posted: 09:13pm 03 Jul 2017
Copy link to clipboard 
Print this post

are the HC12s at VCC=5v or VCC=3v3?

if you have 5V available, try running them at that but putting a 1N4148 or similar reversed between the MM Tx pin and HC12 Rx (so the MM pulls low but does not drive to 3.3v) then your pull up connected to 5V on the HC12 side of the diode. I wonder if the levels are just on the cusp for this HC12
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 09:19pm 03 Jul 2017
Copy link to clipboard 
Print this post

Nice idea, Captain.
I will do that now as part of the latest round of mods.

The problem does indeed seem to stem from the fact that the MM2 pin is left floating when you close the port, so your diode is a nice idea.(not forgetting the 4k7 resistor too)

I've used the HC-12 on the PICAXE chips before and never had this issue, so it was kinda unexpected!

EDIT: Nope, diode and pullup make it go even MORE nuts:



It's fine till the first transmit cycle - same as before, but this time the garbage data goes off the charts very quickly. This is with a diode on TXD, anode to HC-12, cathode to MM2, with 4k7 pull-up to HC-12 and anode of diode.

I will remove this, and change the programming to NOT close the com port and see what happens.
Edited by Grogster 2017-07-05
Smoke makes things work. When the smoke gets out, it stops!
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 09:59pm 03 Jul 2017
Copy link to clipboard 
Print this post

In many embedded systems when a serial port is used it does not change the characteristics of the pins during execution of a program. In MicroMites case the pins can be used for different usages such as input/output/serial, but does one really change a TX/RX pin once used as a serial port to something else later in the program?
I would think that a CLOSE should not change the pins function but just 'close the port in software only' and ignore everything that comes in.
When you use OPEN the pins will be configured for use as a serial port. A CLOSE should not change that.
You have a SETPIN command for that.
Maybe the CLOSE command can be adjusted to not put those pins in an unconfigured state as they would still be connected to a serial device anyway.

Microblocks. Build with logic.
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 11:35pm 03 Jul 2017
Copy link to clipboard 
Print this post

UPDATE:

OK, Things have settled down now, but ONLY if I leave the COM port open all the time, so open it at the start of the code before the main loop, and never close it. I left the 4k7 pull-up to 5v in place, and with this situation, it is working OK - no rogue bytes.

More testing required, but it IS doing what is expected of it now, both the MM2 and the HC-12, but this was a little bit of a curly one....
Smoke makes things work. When the smoke gets out, it stops!
 
CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985
Posted: 11:56pm 03 Jul 2017
Copy link to clipboard 
Print this post

I am bamboozled why it was happening - I will have a play over the weekend and see if I can get the same and then fix.

For me this is a mental exercise as I always leave the port open... but i am curious

glad you got it working - kept you up too
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 01:21am 04 Jul 2017
Copy link to clipboard 
Print this post

  CaptainBoing said   I am bamboozled why it was happening


You're telling me.
Smoke makes things work. When the smoke gets out, it stops!
 
Phil23
Guru

Joined: 27/03/2016
Location: Australia
Posts: 1664
Posted: 01:42am 04 Jul 2017
Copy link to clipboard 
Print this post

Hi Grog,

I've got 6 HC-12's going here;
1 polls 3 slaves, & receives their data,
the other 2 just receive data at this stage (E100's).

No issues like you describe, but as discussed, my coms port gets opened & stays open.

I plan on polling the slaves every 5 seconds, but currently I have the master poll anywhere from every 2 seconds, down to 500mS, just to see how bad I can make things get with conjestion & data overlap.

One little tool thathelped a lot was a HC-12 USB module; nothing more than a HC-12 & something like a CP2102 etc bundled together, but great in that you just bung it into a PC, fire up Teraterm & see what data's floating about & colliding etc.

HC-12 USB

Phil.
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9066
Posted: 04:15am 04 Jul 2017
Copy link to clipboard 
Print this post

Yes, I am reasonably confident that the cause was my closing the COM port, but as MikroBlocks says above - once you decide to use the COM port pins, you don't generally use them for anything else, so I guess I am safe enough leaving it open all the time.

My primary reason for closing it, was just to flush the buffer so that every time it went to send some data, you could be sure it was starting at the start, so to speak, and not adding the wanted data, on to the back of something else still in the buffer.

This does not seem to be happening, so I guess perhaps I was worried about nothing there. Time for sleep.
Smoke makes things work. When the smoke gets out, it stops!
 
CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985
Posted: 04:35am 04 Jul 2017
Copy link to clipboard 
Print this post

  Phil23 said  
One little tool that helped a lot was a HC-12 USB module; nothing more than a HC-12 & something like a CP2102 etc bundled together, but great in that you just bung it into a PC,


That is my wireless network interface to a PC - only difference being it is (usually) the master in the network and uses a ch340 - PCs have superior DB and i/net capability and why break your back? This is the dev one off my desk but installed versions have a stubby antenna on top.



I don't actually have master code running on a MM but am planning so as to have a completely MM solution with a nice big 7" display on a PM MMX board for my snooker hall controller (they are all PC controlled atm but I think there is a market).

I also use a scanner (cheapie Uniden EZI33XLT) to conduct surveys of the sites too - 433.4MHz monitors channel 0 and you can hear the chatter. Great for checking range on distant slave sites.Edited by CaptainBoing 2017-07-05
 
Phil23
Guru

Joined: 27/03/2016
Location: Australia
Posts: 1664
Posted: 07:52pm 04 Jul 2017
Copy link to clipboard 
Print this post

Hadn't thought of using my scanner; I've got a similar older Uniden here.

What I do find very useful though is a Software Defined Radio.

Cheap USB TV receiver dongle ;





Then this Software.

Gives me a cheap & dirty spectrum analyser.





A real one would be nicer, but a bit more than $15.00.

Cheers.



 
     Page 1 of 2    
Print this page
© JAQ Software 2024