rfout vs serout and speed

edmunds

Senior Member
Dear all,

In the process of tuning the PID parameters and finding bugs in the overall algorithm, I have tried to install a small 433MHz transmitter on the car. Then I have another picaxe working with the receiver and showing some of the key parameters in the terminal.

However, at this point this is only a potentially worthwhile debug tool, because a single rfout command row takes enormous time to process if compared to the rest of the loop and does not leave enough time for the car to do what it should do most importantly - watch the line and steer.

Is there a way to replace rfout with serout and should that give a speed advantage? There is little information on what the rfout actually does in the manual. I'm very pleased with the simplicity of the pair of rfout and rfin, but this seem to come at a price - time-wise.


Thank you for your input,

Edmunds
 

edmunds

Senior Member
Sorry if I was not clear the first time around, but the receiver is no problem. It has nothing to do in its life apart from receiving and displaying information from the transmitter. Using rfout on the transmitter is a problem, because that picaxe is sweating as it is at 64MHz. I'm wondering if there is a faster way of doing the same thing as rfout (by bit-banging) a serout or hserout and possibly omit some stuff rfout is doing and I could live without.


Thank you,

Edmunds
 

hippy

Technical Support
Staff member
Most dumb RF links are limited to 2400 baud, 4800 baud if you are lucky, so that can be 4.6ms per byte of data. With preamble and qualifiers you will easily be up to tens of milliseconds.

If you want something fast, HSEROUT is the best bet as that can use baud rates up to 8Mbps.
 

Goeytex

Senior Member
If you are looking for reliable near real-time data from the car to the receiver then you will need to get away from "dumb" ASK RF Devices. There are many smart RF devices to chose from with some supporting RS232 type TTL serial. What you choose depends upon the range and speed requirements and what you can afford.

I really like the INHAOS LC-3000P UART Transceivers. These act like a transparent Serial port and work perfectly up to 115K baud so they will integrate well with Picaxe hserial where you receive data automatically in the background (to the scratchpad). You could even stream data at 115K using the scratchpad as a ring buffer. These are inexpensive with a kit that includes a Master/Slave pair, USB/TTL adapter and nice 3V regulator/connection board. Realistic range is about 150 meters. These operate in the universally legal 2.4Ghz band.

There are many other choices so shop around and find something that will meet your requirements, but I do not think you will ever be happy with the ASK modules.
 

PhilHornby

Senior Member
How much time have you got?

However, at this point this is only a potentially worthwhile debug tool, because a single rfout command row takes enormous time to process if compared to the rest of the loop and does not leave enough time for the car to do what it should do most importantly - watch the line and steer.
Do you know much spare time you've got in your control loop? ... and can you quantify the amount of data you want the transmit, each time around the loop?

Using something like HSEROUT might introduce a new complication, given its asynchronous nature. The first call will complete in a flash, but presumably it could still be executing, the next time round the loop?

Undoubtedly, there will be a status register somewhere that could be queried to detect this ... but accessing it might turn out to be even slower than what you've got now. Even if the firmware implementation of HSEROUT does this itself automatically (does it?), a lot of time could still be wasted, waiting for it to complete.
 
Last edited:

AllyCat

Senior Member
Hi,

RFOUT will be really slow. Not only does it need to transmit the bytes at a slow serial data rate, but it also has to calculate the Manchester encoding. For RF transmission you really need an auxiliary processor; that might be an 08M2 with a simple program or an NKM2401 (which can be decoded by almsot any PICaxe at the receiving end). Or the HC-12 as suggested above but, particularly for "table-top" communications, it really ought be reconfigured for a lower transmit power, since the factory default setting is "illegal" in most countries.

For simple table-top testing indoors, I'd probably use an IR (or visible) LED transmitting a few bytes, either "DC" or modulated at ~40 kHz, using a "spare" PWM output with external hardware or perhaps the PIC's "Data Signal Modulator".

I'm not clear myself how helpful would be HSEROUT. Certainly sending a single character will use very little program time regardless of the baud rate. Or to be absolutely sure you could just throw the byte at the chip hardware with a POKESFR . However, if you send a string of characters to HSEROUT, which could be sent at a much higher baud rate (but not with a dumb RF transmitter), does it actually use interrupts, or still "block" other program commands until the last character is reached?

Cheers, Alan.
 

Buzby

Senior Member
.... does it actually use interrupts, or still "block" other program commands until the last character is reached?

Cheers, Alan.
hserout a single byte at any baud rate takes microseconds, but hserout more than one byte takes the time it needs for the first byte (microseconds) plus the time it needs to send the remainder of the string at the baud rate hserout is using. (milliseconds)

When hserout is called, it checks the UART status flag, and waits if it is busy. Normally it is not busy, so hserout writes the byte to the UART, and if that was the only byte hserout returns immediately. However, if the hserout command has more than one byte, it waits for the busy flag to clear before sending each byte, so it takes as long as the baud rate needs.

I discovered all this when I had a problem with hserout inside an interrupt, and it took a lot of head scratching to find out why it sometimes worked, but mostly didn't.

Cheers,

Buzby
 

AllyCat

Senior Member
Hi,

Thanks for that Buzby; that's what I had suspected.

So edmund's options for using a dumb RF transmitter are quite limited. HSEROUT won't help (much) and I now see that the NKM2401 only communicates with its "host" at 2400 baud (and must receive 8 byte blocks of data). :(

Perhaps the "simplest" radio solution might be to use an auxiliary 08M2 to receive serial characters at a high baud rate, Manchester Encode (lookup table?) and send to the dumb transmitter. Or just use an off-the-shelf HC-12.

Cheers, Alan.
 

edmunds

Senior Member
This has turned into a very informative discussion and thank you for that, guys. The consensus, however, seems to be radio is not a quick and dirty debug option in this case. Not the end of the World at all.

Best regards,

Edmunds
 

lbenson

Senior Member
Since Edmonds is not looking for two-way communication, and for visual debugging purposes even the odd error would not likely matter, I don't see why a single byte sent with serout (or hserout) through a dumb 433mHz transmitter at every pass through the loop would not suffice. This would add some time on the sending side to organize the sensor information and tracking directive into a single byte of information and we don't know (as per PhilHornby) exactly how much time is available in the loop.

Synchronization of the rx for serout could be done at the start of the program with 'serout Tx433, N9600_32, ("UUU")' (or whatever baud rate, per womai's trick: http://www.picaxeforum.co.uk/showthread.php?11531 ). The frequency of transmission thereafter would probably be sufficient to keep the receiver from going out of sync (untested).

The time lost in organizing the data into a single byte would be much less than the time lost in sending additional bytes.

For instance, a single byte with the high bit low could tell you which of 128 bits you have calculated to be the center of the line: %01000000 -- bit 64--dead on center.

A single byte with the high bit high could, if decoded into nibbles, give you 8 categories of data with 16 possible values each: %10010001 -- first message of first category. Or straightforwardly, 128 separate messages.

Telemetry rules.
 
Last edited:

PhilHornby

Senior Member
Testing...

When hserout is called, it checks the UART status flag, and waits if it is busy. Normally it is not busy, so hserout writes the byte to the UART, and if that was the only byte hserout returns immediately. However, if the hserout command has more than one byte, it waits for the busy flag to clear before sending each byte, so it takes as long as the baud rate needs.
I just did a test on a 20X2, and can confirm that behaviour - i.e. it is synchronous (well apart from the last byte).
Code:
[COLOR=navy]#picaxe [/COLOR][COLOR=black]20x2[/COLOR]
[COLOR=navy]#terminal 115200
#no_table[/COLOR]
[COLOR=blue]symbol BAUD[/COLOR][COLOR=darkcyan]=[/COLOR][COLOR=blue]B115200_64                                [/COLOR][COLOR=green];for hserout
      [/COLOR][COLOR=blue]low C.1
      low b.7
      pause [/COLOR][COLOR=navy]2000                                      [/COLOR][COLOR=green];wait for terminal to initialise
      [/COLOR][COLOR=blue]setfreq M64
      hsersetup BAUD[/COLOR][COLOR=black],[/COLOR][COLOR=navy]%10                              [/COLOR][COLOR=green];inverted o/p, like SERTXD[/COLOR]
[COLOR=blue]do
      high C.1
      
      high B.7                [/COLOR][COLOR=green];high (32uS later)
      [/COLOR][COLOR=blue]hserout [/COLOR][COLOR=navy]0[/COLOR][COLOR=black],[/COLOR][COLOR=blue]([/COLOR][COLOR=red]"A"[/COLOR][COLOR=blue])         [/COLOR][COLOR=green];78uS
      
      [/COLOR][COLOR=blue]toggle B.7              [/COLOR][COLOR=green];low
      [/COLOR][COLOR=blue]hserout [/COLOR][COLOR=navy]0[/COLOR][COLOR=black],[/COLOR][COLOR=blue]([/COLOR][COLOR=red]"BC"[/COLOR][COLOR=blue])        [/COLOR][COLOR=green];184uS
      
      [/COLOR][COLOR=blue]toggle B.7              [/COLOR][COLOR=green];high
      [/COLOR][COLOR=blue]hserout [/COLOR][COLOR=navy]0[/COLOR][COLOR=black],[/COLOR][COLOR=blue](cr[/COLOR][COLOR=black],[/COLOR][COLOR=blue]lf[/COLOR][COLOR=black],[/COLOR][COLOR=red]"Now is the Winter of our discontent, made glorious Summer by this son of York"[/COLOR][COLOR=blue])[/COLOR][COLOR=green];79 characters @ 115200baud = 6.9mS, (Measured @ 7.5mS)
      
      [/COLOR][COLOR=blue]toggle B.7              [/COLOR][COLOR=green];low
      [/COLOR][COLOR=blue]hserout [/COLOR][COLOR=navy]0[/COLOR][COLOR=black],[/COLOR][COLOR=blue](cr[/COLOR][COLOR=black],[/COLOR][COLOR=blue]lf[/COLOR][COLOR=black],[/COLOR][COLOR=red]"Oh the sirens are screamin' and the fires are howlin', way down in the valley tonight"[/COLOR][COLOR=blue])[/COLOR][COLOR=green];87 chars @ 115200= 7.6mS, (Measured @ 8.3mS)
      
      [/COLOR][COLOR=blue]toggle B.7              [/COLOR][COLOR=green];high
      [/COLOR][COLOR=blue]toggle B.7              [/COLOR][COLOR=green];low  (33uS pulse)
      
      [/COLOR][COLOR=blue]low C.1                 [/COLOR][COLOR=green];16.7mS after going high
      [/COLOR][COLOR=blue]Pause [/COLOR][COLOR=navy]40000             [/COLOR][COLOR=green];5 seconds[/COLOR]
[COLOR=blue]loop[/COLOR]
This surprised me, because in the past I'd swapped from using SERTXD to using inverted HSEROUT (on a 14M2); the reason being that SERTXD was making my TIME variable run slow, whereas HSEROUT didn't.
 

AllyCat

Senior Member
Hi,

; the reason being that SERTXD was making my TIME variable run slow, whereas HSEROUT didn't.
Yes, presumably HSEROUT doesn't need to disable (time) interrupts (whilst waiting for the hardware to become free) whereas SERTXD does need to disable them to achieve accurate bit-timing.


I don't see why a single byte sent with serout (or hserout) through a dumb 433mHz transmitter at every pass through the loop would not suffice. This would add some time on the sending side to organize the sensor information and tracking directive into a single byte of information and we don't know (as per PhilHornby) exactly how much time is available in the loop.

I also considered sending a single byte, but decided it probably wouldn't work well (if at all). From another thread we know that edmund's target loop time is around 20 Hz (50 ms) and may be much longer, whilst womai was suggesting a PAUSE of around only 5 ms: "Just don't wait much longer than one byte, otherwise the receiver will lose lock again".

Cheers, Alan.
 

Buzby

Senior Member
Sertxd uses software timing to wiggle a pin and control baud rate, but hserout uses hardware counters directly connected to the UART, so no effect on any picaxe timers.
 
Last edited:

inglewoodpete

Senior Member
Since Edmonds is not looking for two-way communication, and for visual debugging purposes even the odd error would not likely matter, I don't see why a single byte sent with serout (or hserout) through a dumb 433mHz transmitter at every pass through the loop would not suffice.
Continuously sending a single byte via a 433MHz wireless link is likely to cause some problems in built-up areas. 433MHz is used for many other purposes in most countries, including car door openers, garage doors etc.

By running the transmitter continuously, there is likely to be interference to these other systems that share the 433MHz band.
 

hippy

Technical Support
Staff member
The best bet would probably be to use two PICAXE chips. The master sends out a single byte at any baud rate using HSEROUT which has almost zero overhead. The second will receive a byte and then have the full loop time of the master to send out a slow packet via a dumb RF transmitter. It possibly has longer because it could skip bytes it wasn't ready for, only send the latest and up to date data.
 

edmunds

Senior Member
The best bet would probably be to use two PICAXE chips. The master sends out a single byte at any baud rate using HSEROUT which has almost zero overhead. The second will receive a byte and then have the full loop time of the master to send out a slow packet via a dumb RF transmitter. It possibly has longer because it could skip bytes it wasn't ready for, only send the latest and up to date data.
Yes, thanks, @hippy, that was my plan if it turns out I need to revert to receiving data at some point. I think, Buzby has showed in another thread data input into the simulator returns enough of the error. I will revert to actual data from the car when that is fixed and if it is still failing the reality test.

Building a picaxe RFOUT slave board would actually be a good investment of time and money, since this is probably not the last project that could benefit from some data link with a difficult to wire down device :)

Edmunds
 

lbenson

Senior Member
The best bet would probably be to use two PICAXE chips. The master sends out a single byte at any baud rate using HSEROUT which has almost zero overhead. The second will receive a byte and then have the full loop time of the master to send out a slow packet via a dumb RF transmitter. It possibly has longer because it could skip bytes it wasn't ready for, only send the latest and up to date data.
My own thought, after I went to bed. Why visions of picaxes instead of visions of sugarplums?
 
Top