What's the function of [timeout] before serin ?

JanJor

Member
Dear forum,

I'm using a 28X2 to send a number to a second 28X2, using the well-known DORJI transmitter/receiver. Extremely straightforward. It's just a test set-up to check the reliability of the transmission. That works OK, no problems here.
BUT; I want to check the reliability of the transmission as follows: if the first 28X2 sends a number and the second one does NOT receive anything, it should be able to let me know (message to OLED) and then go back to serin to check again if there is a message.

If I use the standard serin command, in this case serin, b.2,n600_4,("PX"), b1, the picaxe will of course wait forever if it does not receive anything.

Here's the problem: I expected that including a timeout in the the command as follows: [1000,aap],serin, b.2,n600_4,("PX"), b1 would do the follwing:

1) wait for 1 second if anything is received from the transmitting 28X2
2) if a message arrives go to the next program line
3) if NO message is received within that second, go to aap: and then do what it has to do under aap:, display "missed transmission" on the OLED.

For some reason this does not work: the 28X2 still "hangs"; it still keeps waiting forever for a message from the sender.

Before bothering you with the details of the program, I'd like to know: do I misinterpret the function of the timeout-command?

I've extensively searched the forum, but did not find the answer I was looking for.

Even a short hint from the forum members would already be helpful.

Thanks in advance,

Ronald
 

lbenson

Senior Member
My understanding from a thread I can't find now is that timeout doesn't really work reliably with wireless transmissions, because there is always noise on the line, so it doesn't time out.

I suggested at the time that when a prefix is used, the timeout should occur if the prefix is not found within the timeout limit, but that has not been implemented.
 

inglewoodpete

Senior Member
My understanding from a thread I can't find now is that timeout doesn't really work reliably with wireless transmissions, because there is always noise on the line, so it doesn't time out.

I suggested at the time that when a prefix is used, the timeout should occur if the prefix is not found within the timeout limit, but that has not been implemented.
lbenson - Perhaps this is the 2013 post you refer to? http://www.picaxeforum.co.uk/showthread.php?14813-Serin-hoggs-the-entire-system&p=238380&viewfull=1#post238380

In the following post, #11, WA55 suggests using the AXE213 for a more reliable wireless connection. This is the solution I will be pursuing in the coming weeks - I have 2 pairs of AXE213s winging their way across the world for me to experiment with.
 

premelec

Senior Member
Hi IP - the AXE213 appears to just be an implementation of the Manchester encoding which is available with RFIN RFOUT commands on M2 units... is that your understanding? Have you tried 14M2 RF IN/OUT for example?
 
Last edited:

inglewoodpete

Senior Member
Hi IP - the AXE213 appears to just be an implementation of the Manchester encoding which is available with RFIN RFOUT commands on M2 units... is that your understanding? Have you tried 14M2 RF IN/OUT for example?
Correct. I'm hoping the treat the wireless link like a "black box" (perhaps that should be two black boxes, since it will be a both way connection). Obviously, there will need to be additional error checking and handshaking between the PC and PICAXE.

I have to admit that I've never used wireless to date, so my learning will start when the AXE213s etc arrive! This is a paid commission, so the cost (about A$100/US$70/GBP50 delivered) for the bothway connection is covered by the client. The real cost is my time, so I want it to work reliably as quickly as possible. The connection will be to the background hSerial port of a 28X2. I'm currently using an AXE027 cable to connect to the hSerial port but that won't be possible when we install the gear. (M2 series are great chips but I don't use them very often.)
 

premelec

Senior Member
From the manual on RFIN/OUT:

"This command is equivalent to using an NKM2401 encoder to transmit the data.
Therefore if using a PICAXE chip that does not support this command, simply
use a NKM2401 encoder instead."

28X2 supports RFIN/OUT... You have a lot more experience than I and I hope it works!
 

inglewoodpete

Senior Member
Also from the manual: "Note this (rfin) command is blocking, no other commands will process whilst the rfin
command is waiting for RF data to be received
."

As mentioned previously, I'm using background serial reception so that other parts of my program can keep running while data is being received. Hence my desire to use external encoder chips.
 

premelec

Senior Member
Thanks for that reminder... I figured there was some reason but wasn't discerning what it was... :)
 

JanJor

Member
Dear forum, Rossko57 and Ibenson,

I would never have thought about the fact that idling RF receivers output noise that prevent timeouts activating (although after I saw your comments it sounded perfectly logical).

It could easily be tested: I just disconnected the receiver from the Picaxe and indeed, then the timeout command works perfect. So indeed the output noise of the (cheap) DORJI when idle causes the problem.

I''ll take the easy way out and just add an 8M to which I'll connect the receiver and let the 28X2 check for messages on the 8M.

As always: thanks for your help.

Kind regards,

Ronald
 

edmunds

Senior Member
Maybe a crazy idea, but could you not use i2c protocol for wireless? It has all the handshakes and acknowledges built in. Replying from the phone now, so cannot paste a link, but there was a recent post, where somebody was doing just that.

Good luck,

Edmunds
 

lbenson

Senior Member
The noise is probably ambient. Unless you're in a rural area, lots of 433mHz xmtters and other noise generators may be about,
 

inglewoodpete

Senior Member
Maybe a crazy idea, but could you not use i2c protocol for wireless? It has all the handshakes and acknowledges built in. Replying from the phone now, so cannot paste a link, but there was a recent post, where somebody was doing just that.

Good luck,

Edmunds
Maybe it is a crazy idea :)! I can't imagine how you'd get clock and data signals over a single radio channel without some fancy encryption. Unless, of course, the i2c is communicating with some sort of 'smart' wireless transceiver and not with the far end device.
 
Top