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 ZealandPosts: 9066 |
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? Smoke makes things work. When the smoke gets out, it stops! |
||||
piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
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. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
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 |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
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 ZealandPosts: 9066 |
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 ZealandPosts: 9066 |
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 ZealandPosts: 9066 |
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 ZealandPosts: 9066 |
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: AustraliaPosts: 5913 |
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: 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 ZealandPosts: 9066 |
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. Smoke makes things work. When the smoke gets out, it stops! |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
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 ZealandPosts: 9066 |
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. Smoke makes things work. When the smoke gets out, it stops! |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
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 ZealandPosts: 9066 |
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 KingdomPosts: 1985 |
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 ZealandPosts: 9066 |
You're telling me. Smoke makes things work. When the smoke gets out, it stops! |
||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
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 ZealandPosts: 9066 |
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 KingdomPosts: 1985 |
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. |
||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
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 |