TheBackShed.com

Forum Index : Microcontroller and PC projects : Interesting MM vs PICAXE serial....

Author

Message

Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9590

Posted: 11:40pm 04 Jul 2016

Copy link to clipboard

Print this post

This is interesting, and took me a day or so and the logic analyser to work out what the hell was going on.

In the original system, which is based on PICAXE, there are no problem with this serial string sent by the RF module:

However, when I use this exact same serial string from a MM+ controlling the same RF module, the PICAXE system never sees the entire message - it was always two bytes short.

The solution was to remove the \r and \n bytes from the data stream after the [BRVL] pre-requisite, then everything worked:

Interesting though. Bit of a head-scratcher till I was able to put the logic analyser on one of the call-points and compare that to the output from the MM-based RF node. They were BOTH sending the same string, but the PICAXE base system would not pick up all the data from the MM node, but it would respond every single time to the PICAXE nodes that had the extra CR and LF bytes in the data stream.

Removing the \r and \n that is in place on the PICAXE nodes, from the MM+ node, and the PICAXE base unit sees the transmissions from both.

My only explanation for why that should be, is that the MM is just too fast.

The PICAXE chips run at 8MHz(18M2's at default), and the MM is running at 60MHz, which is throttled back for the MM+.

My guess is that with PICAXE nodes and the PICAXE base unit, there was some natural delay going on there between the pre-requisite and the message in PICAXE processing time, which does not exist in the MM+ due to the speed difference.

I'd be interested in other members comments on the reasons behind this phenomenon though.

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

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2431

Posted: 03:21am 05 Jul 2016

Copy link to clipboard

Print this post

as i recall, there may be some issues with certain devices not being spot-on with their baud rates - the lower the system clock rate, the harder it is to get an exact baud rate match. combine this with a long string of continuous characters and it can become possible to get out of sync.

if using com1, try setting 2 stop bits (S2). or output characters one at a time and introduce a suitable pause between sending each one.

cheers,
rob :-)

Print this page

To reply to this topic, you need to log in.