 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 : MM-PICAXE RF link... :(
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
This one has me scratching my head. The original project used a PICAXE 14M2 and SEROUT to send data to a Radiometrix NTX2 transmitter module at 2400 baud. The Micromite version uses exactly the same message bytes, but the PICAXE-based receiver only sees garbage. There is no valid message. I decided to capture BOTH the PICAXE based unit, and the new Micromite unit data output on my logic analyser to see if it could help me solve the problem: PICAXE DATA OUTPUT:  MICROMITE DATA OUTPUT:(CSub on pin-7 of an Explore-28 module)  Channel-1 of the capture is the data output. Channel-2 of the capture is the ENABLE line to the NTX2 module. On the Micromite version, I have extended the ENABLE out from 5ms to 100ms, so that I can hear the burble on my scanner radio. The data is most definitely being transmitted, but the PICAXE based receiver only gives me corrupted data - which is odd, as the baud-rate is the same, both use the same number of preamble 'U' bytes, and both use the ENABLE line. I have saved the captures, so if anyone has the Saelie Logic hardware and software here, I can upload, but I won't just for the moment. The PICAXE seems to introduce about 4-5ms of delay between the message and the last byte(the mode byte), which can be either 'H' or 'R'. I thought perhaps the Micromite - being much faster then the PICAXE - might be streaming data too fast for the PICAXE to process it at the other end, so I introduced a 5ms delay between sending the payload and the mode byte, but it made no difference at all.  The reason I did this, was that in the PICAXE-based transmitter node, there is a 4-5ms delay between the payload and the mode byte. This is NOT by design, it is due to the time required for the PICAXE to decide what mode byte to send along with the payload. The PICAXE code for the receiver is:  EXTREMELY simple, but does NOT work with the same message - at the same baud-rate, sent via a MM chip - but it DOES work 100% of the time if a PICAXE chip sends the exact same message.  I need a drink.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Beer can work!  Fixed it. Working. An update will be posted shortly..... Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
OK, folks. When I examined the captured data, I could see that there was a delay of 1.8ms between sending the preamble+qualifier, then another 1.8ms delay between the qualifier and the payload, followed by the biggest delay - about 4-5ms between the payload and the mode byte. Obviously, the PICAXE is quite specific there, and when you use two PICAXE's - one at each end - there is no problem, as the delays are pretty much the same, so they sync up without issue. The MM, on the other hand, is much faster and just sends all the data at once, and the PICAXE at the receiver end can't keep up, and a few bits are missed on some of the data packet, and so you end up with corrupted data.(at the receiving end) So, what I did, was introduce 2ms delays between the preamble and qualifier, and another 2ms between the end of the qualifier and the payload, then a final 5ms between the payload and the mode byte. The PICAXE receiver now decodes the message 100% correct. Progress.  Smoke makes things work. When the smoke gets out, it stops! |
||||
CircuitGizmos Guru  Joined: 08/09/2011 Location: United StatesPosts: 1427 |
You owe everyone that helped you a beer! Micromites and Maximites! - Beginning Maximite |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
On previous attempts to talk to the picaxe from 'mites, you needed two stop bits to give the picaxe time to think. Jim VK7JH MMedit |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
@ CG: "Mmmmmmmmmm. Beeeeeerrrrr....." (Homer Simpson) @ Jim: Yes, you are right. As I am using the CSUB SerialTX routine, there is no allowance for extra stop bits like the native COM1 and COM2 syntax allows for. COM1 and COM2 are already assigned. To anyone else reading this who has ever had garbled comms on serial, or other protocol communication issue(SPI, I2C RF links etc), a good logic analyser is worth it's weight in gold. I would have been floundering for ages trying hit-and-miss methods to try to work out why the data was garbled at the PICAXE end, when it was fine going out if not for the help of the logic analyser. While a scanner radio is useful to know there is a transmitted signal at the frequency of interest, the scanner radio won't tell you about those crafty little delays that the PICAXE introduces into the datastream while it is processing what to do, and without a way to see that - you're stuffed. The Saelie Logic unit is one of the best bits of test kit I have ever bought since I started playing with micro-controllers. Smoke makes things work. When the smoke gets out, it stops! |
||||
Timbergetter Regular Member  Joined: 08/10/2018 Location: AustraliaPosts: 55 |
Good to hear you have tracked down the culprit. I would be interested to hear your opinion on how you might have gone troubleshooting the problem on a DSO rather than the Saleae. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
It's funny you should mention that, as getting a DSO is one of my recent threads, and although I have not given up on that yet, I am still trying to make up my mind on which one to go for.  As with the Saelie, if I had a DSO, I would have connected the serial to channel-1, and the ENABLE line to channel-2 and run the serial decoder part of the DSO - which would have given me basically the same result as the Saelie. The beauty of a DSO, is that once they have captured the waveform, you can zoom in with much more detail then the Saelie - with no disrespect to the Saelie. I could also have put the other setup on channel-3 and channel-4. I could do this with the Saelie too, but it was easier to capture one device, then the other separately. Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
I agree Grogster, the Saleae is one of the best tools in my arsenal. It has saved me a few headaches with I2C, UART and SPI when you can see EVERYTHING that is happening and try and locate the bugs, as you can attest to. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
+1 on the Seleae. I bought a cheap chinese knock-off which worked with their software. The hardware was very limited but I was so impressed with what the software did even with a PoS copy I went the whole hog and splashed out (£300 ish?) on their little 8 channel black square. It has been invaluable! I built a frequency meter based around a 12.288MHz TCXO at 100ppb so the gate is incredibly precise... couldn't get it to read properly with a precision frequency source and this little seleae helped me trace it down to a design fault that was taking 78uS off every gate, all within about 15 minutes after I started analyzing with it... would have taken days if at all with out it. Literally one of the best tools in my shed, doesn't get used often but when it does it *always* delivers. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Yes indeed. While I am not quite that keen to spend the money on a good DSO - and while I decide which one I finally want - the Saelie thing is a fine substitute!  Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
