Serial, Wireless etc. Questions

C

calvinsykes

Member
I'm trying to get two 14Ms to talk over a 433Mhz radio link. I know the radio link is working because there's an LED on the reciever side that blinks in time with one on the transmitter side.

If I don't include a check for a qualifier in the reciever code, I see random gibberish; if I do, the PIC doesn't see anything. I'm also using the 0x55 preamble. Full code below:

Tx:

Code: 
init: let b0 = 33
main: high 4
	serout 5, T600_4,  (0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55)
	low 4
	pause 20
	high 4
	serout 5, T600, ("data", b0)
	low 4
	pause 500
	goto main
Rx:

Code: 
main: let b0 = 0
	serin 0, T600_4, b0
	debug
	goto main
Tx is on 4.5V; Rx is on 6V regulated to about 5.3-ish V with a potentiometer (temporary solution until I get a proper voltage regulator), but both in limits.

I've got a few possible theories:

  1. T or N signals?
  2. Does serin need a 10k pulldown?
  3. 10k pullup on Tx data?
  4. 100nf capacitor in series on Tx data?
  5. ...and any on Rx?
  6. Rx output is buffered on a BCX38C (darlington npn). Is this appropriate?

Please comment on some of theese! :)
 
A

Andrew Cowan

Senior Member
You'll need to use a qualifier - otherwise you'll just read in the random noise that is in the background.

Tx is on 4.5V; Rx is on 6V regulated to about 5.3-ish V with a potentiometer (temporary solution until I get a proper voltage regulator), but both in limits.

There's the first problem. You can't use a potentiometer for this sort of supply, as when the load increases, the current drops. If you looked at the signal on a scope, you'd see the supply fluctuating and dripping out whenever data is received. You need a proper regulator (or failing that, LOTS of capacitors including low ESR ones).

T or N signals?

Doesn't matter - either is OK. However, some of the radio modules I have used invert the signal, so it could be that the transmitter and receiver need to be different.

Does serin need a 10k pulldown?

It depends on the radio module - do you have a datasheet? It's more likely to be a pullup actually - some modules have an open collector output.

10k pullup on Tx data?

No - PICAXE outputs are totempole outputs.

100nf capacitor in series on Tx data?

No - you'll distort your square wave of data. 100nF on all the power pins, though.

...and any on Rx?

As above.

Rx output is buffered on a BCX38C (darlington npn). Is this appropriate?

Why? :confused:

Welcome to the forum!

Andrew
 
Last edited:
M

MartinM57

Moderator
Reducing a voltage to power something by using a potentiometer doesn't usually work well - if you want to drop 0.7 volts then use a series diode (or two, if the current draw is low).
 
C

calvinsykes

Member
The pullup was there because of this: http://www.picaxe.orconhosting.net.nz and the pulldown because I assumed you'd need one as you do when working with normal 'one or zero' inputs. And the transistor was just to power the LED so I could see what was going on.

But anyways, I removed them and it works, so thanks!
 
W

william47316

New Member
send the quailifier with the main data
chuck out the ASCII, not needed and can complicate things a little on the receiver

and use something like
(170,170,170,170,85,170, byte) in the transmission
and (170,85,170), byte
in the receiver
 
Last edited:
W

westaust55

Moderator
william_47316 said:
send the quailifier with the main data
chuck out the ASCII, not needed and can complicate things a little on the receiver

and use something like
(170,170,170,170,85,170, byte) in the transmission
and (170,85,170), byte
in the receiver
Click to expand...
I think that some reconsideration and explanation is needed here.

chuck out the ASCII,
Click to expand...
What precisely is wrong with a simple ASCII qualifier ? :confused:

Certainly even a simple “ABC” has not caused myself any problems even though there are significant gaps between 1’s (eg “A” = %10000001)

Sure you are not using obvious ASCII characters as a qualifier directly but by your own admission you have (170,85,170) as a qualifier so hardly “chucked out” and 85 is just the ASCII equivalent of “U”. Even 170 is just a lower case “x” so for all intents you have a qualifier of "Ux".

If you have one or more receivers working in conjunction with two or more transmitters as some here have done then you need a different qualifier for each Transmitter in which case the simple (170,85,170) just “will not cut the mustard”.
 
W

william47316

New Member
westaust55 said:
I think that some reconsideration and explanation is needed here.



What precisely is wrong with a simple ASCII qualifier ? :confused:

Certainly even a simple “ABC” has not caused myself any problems even though there are significant gaps between 1’s (eg “A” = %10000001)

Sure you are not using obvious ASCII characters as a qualifier directly but by your own admission you have (170,85,170) as a qualifier so hardly “chucked out” and 85 is just the ASCII equivalent of “U”. Even 170 is just a lower case “x” so for all intents you have a qualifier of "Ux".

If you have one or more receivers working in conjunction with two or more transmitters as some here have done then you need a different qualifier for each Transmitter in which case the simple (170,85,170) just “will not cut the mustard”.
Click to expand...


to each there own, however by ascii i was meaning the printed characters not explicitly the specific numbers which the ascii is assigned. as i dont exactly use more than one wireless unit what i have mentioned will be fine if you DONT have more than one unit or want to broadcast over multiple receivers. if neaded by all means use the ascii in the qualifier but use something a bit more simple like a number ID
 
Last edited:
hippy

hippy

Ex-Staff (retired)
william_47316 said:
send the quailifier with the main data
chuck out the ASCII, not needed and can complicate things a little on the receiver

and use something like
(170,170,170,170,85,170, byte) in the transmission
and (170,85,170), byte
in the receiver
Click to expand...
Actually that's a very bad idea. The issue is disguised by giving numbers in decimal rather than hex or binary but -

170 = $AA = %10101010
85 = $55 = %01010101

The use of a qualifier is to strip out data where there may have been a dropped or induced data bits and those are too close to give reliable error detection. The reason for using ASCII is that those bytes will be significantly different from the preamble to minimise errors which make it through. Even with ASCII there are good and bad choices depending on how different ( at the binary level ) the characters are; "ABAB" is not as good as "AZBY".

It's also desirable to put a pause between sending the preamble (170) and the ASCII qualifiers to make sure the receiver has synchronised properly and hasn't part way through one byte and into the next. Synchronising to the preamble and qualifier (170,85,170) is likewise not a good idea.

For the actual preamble, whether 170/$AA or 85/$55 is best depends on what serial polarity is used; Nxxxx or Txxxx. The idea is to send a continuous steam of alternating 0 and 1 bits taking into account the bit order sent and the serial start and stop bit framing.

There is a lot more to bit-banged wireless than it first appears, requires a deep understanding of what's going on at the lowest signal level, and it's much easier to use the NKM2401 than bit-banging.

http://www.techsupplies.co.uk/NKM2401
 
W

william47316

New Member
just putting my one out there, im just showing you what manages to work for me. jeez dont start a flame war on my part
 
Last edited:
hippy

hippy

Ex-Staff (retired)
Actually the preamble should always be $55 / 85 / "U", regardless of serial polarity.

I suspect the 170 / $AA which I've seen in other example code has crept in as a result of people somewhere down the line not understanding the subtleties of transmitted bit order and polarity inversions of serial and pressuming $AA is better than $55, not understanding the underlying theory of operation or what that is attempting to achieve.

Code: 
This is what $55+$55 sent with Txxxx looks like -
         _   _   _   _   _   _   _   _   _   _
      |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
       S 1 0 1 0 1 0 1 0 E S 1 0 1 0 1 0 1 0 E
Code: 
This is what $AA+$AA sent with Txxxx looks like -
           _   _   _   ___     _   _   _   ___
      |___| |_| |_| |_|   |___| |_| |_| |_|
       S 0 1 0 1 0 1 0 1 E S 0 1 0 1 0 1 0 1 E
Code: 
This is what $55+$55 sent with Nxxxx looks like -
       _   _   _   _   _   _   _   _   _   _
      | |_| |_| |_| |_| |_| |_| |_| |_| |_| |_
       S 1 0 1 0 1 0 1 0 E S 1 0 1 0 1 0 1 0 E
Code: 
This is what $AA+$AA sent with Nxxxx looks like -
       ___   _   _   _     ___   _   _   _
      |   |_| |_| |_| |___|   |_| |_| |_| |___
       S 0 1 0 1 0 1 0 1 E S 0 1 0 1 0 1 0 1 E
The intent is to give a continuous sequence of alteranting 0 and 1 bits. This allows the receiver to be best primed for subsequent data reception. $55 / 85 / "U" achieves that in a perfect world, $AA / 170 does not.

In the imperfect world we have using SEROUT there will be 'bit-stretch' between the stop bit (E) and start bit of the next byte (S). This will make it closer to sending 170, but sending 170 will become even further from ideal.

It could be argued that as it's not perfect anyway it doesn't matter, however the closer we can get to ideal the better.

The need for a PAUSE between preamble and the data qualifier is because it's not know when the receiver will be primed for use, when the first received bits will get passed on to SERIN. The SERIN could then synchronise to any bit of the preamble and take that as a start bit. The pause ensures that that first bit it sees after preamble is a genuine start bit of qualifier -


Code: 
                                              |<-- PAUSE -->|
       _   _   _   _   _   _   _   _   _   _  :             :_   _
      | |_| |_| |_| |_| |_| |_| |_| |_| |_| |_:_____________| |_|
       S 1 0 1 0 1 0 1 0 E S 1 0 1 0 1 0 1 0 E        :     :S 1 0 etc
                                  :                   :     :
                                   S a b c d e f g h E       S a b
                                   Mis-synchronised          Synchronised
 
hippy

hippy

Ex-Staff (retired)
william_47316 said:
just putting my one out there, im just showing you what manages to work for me. jeez dont start a flame war on my part
Click to expand...
No intent to flame if it came over that way, just to explain and educate. A lot of people seem to get stuck with wireless, don't get the expected results and that takes up considerable time on the forum which may be avoided if they start from sound principles.
 
W

william47316

New Member
yes ok i'll admit i have changed my qualifier to use an ASCII ID something like ":01" or something should do for the most part 100 unique id's should suffice i should think
using all 170's for level setting or some such has worked ok but seeing the earlier post showing the waveforms has told me otherwise i shall change to 85's then
 
hippy

hippy

Ex-Staff (retired)
william_47316 said:
seeing the earlier post showing the waveforms has told me otherwise i shall change to 85's then
Click to expand...
Or maybe not ... in an imperfect world with bit-stretch between S and E, the $AA bit-stretch may better counter that, give a better average 'zero-DC' ! The decision on which to use may depend on whether using SEROUT or HSEROUT.

And maybe those I assumed had 'got it wrong' have 'got it right'. It would really take someone with detailed knowledge of RF modules to answer that.

As has been said, there's nothing simple about SEROUT bit-banging wireless on a PICAXE.
 
W

william47316

New Member
new transmit receive code for my wireless modules
transmit:
serout 0, n2400, (85,85,85,85,85,85,85)
pause 5 (note it is running at 8Mhz so it'll be 2.5mS)
serout 0, n2400, (":01",b1,b2,b3,b4,b5,b6,b7,b8,checksum)

receiver end:
serin 3,n2400, (":01"),b1,b2,b3,b4,b5,b6,b7,b8, checksum
 
hippy

hippy

Ex-Staff (retired)
I think that's much better.

The PAUSE value can be calculated from baud rate, sending 10 bits ( data plus start and stop ) plus a bit more for good measure. At 2400 baud, 10 bits is ~4ms, so 5ms is a good choice. That should be a 5ms though no matter what the operating frequency so PAUSE 10 at 8MHz.

Too long for the PAUSE and the receiver starts to lose the priming set by the preamble, too short and you don't fully protect against mis-synchronisation.
 
M

manuka

Senior Member
Hippy: An absolutely top notch explanation & your lucid ASCII art quite made my day.

William_47316: Hope that "85" approach tames it. I've long used this to good effect myself.
 
N

nickwest

Member
pause value at slow bitrates?

I'm using 300baud (for reliability: I only need to send one byte every minute or so). Can anybody recommend the right PAUSE time between the sync characters and the qualifier? So far I haven't used a pause and it hasn't given me bad data... but we all know that the failure _will_ happen, and at a critical time!

serout 2, N300_4, (85,85,85,85,"ABC",b1)

Oh and for error correction I simply send the same byte twice. If byte 1 != byte 2, ignore them both and wait for the next two bytes. Not efficient, but very simple to write. Slowly-changing values are great!
 
Last edited:
N

nickwest

Member
Sorry, I just saw Hippy's post #19, so it sounds like 30ms should be about the right "PAUSE" time at 300baud. Does that sound OK?

I'm getting nervous now that the pause will be so long that the AGC of the RF module will have started to drift again and let more noise through. I might put a scope across the output pin of the RX and have a look.
 
You must log in or register to reply here.
Top