Slow serial baud rate

[charleswenzel]

I read in the manual that higher clock speeds also speed up the serial baud rate, say using sertxd. But I haven't found any info on whether a very slow clock (31 kHz, for example) would also slow the baud rate (which is what I want). Seems like it would. Does 31 kHz result in a slow 37 Hz baud rate on an 08M2? I'm contemplating sending serial on a bandwidth-limited channel, clean but slow.

 

[papaof2]

If you're up to the work, that's wel within the limits of "bit-banging" serial - but you'll need someone with more recent experience with slow serial on a PICAXE. I no longer have samples of that - sometimes laptops grow legs and "walk off" :-(

 

[Aries]

The simple answer is "yes". The sertxd baud rate is tied to the clock speed and varies in proportion to it.

 

[AllyCat]

Hi,

Yes, in principle it could work, but there are at least two potential "gotchas", both concerned with the "Watchdog Timer" of the base PIC chip. Firstly, AFAIK the "31kHz" oscillator is the Watchdog Timer, which has a far lower accuracy than the regular PIC's clock oscillator. The base PIC data sheet specifies the Watchdog Timer accuracy as +/- 25% (originally it was a highly pessimistic -50% to +100%), which probably isn't good enough for the maximum +/-5% you're likely to need for reliable "RS232" serial communications. If you look into the depths of the base PIC data sheet, there is also a "32kHz" oscillator mode but I don't believe the PICaxe OS uses that.

Secondly, the Watchdog Timer is active in (all) PICaxes after a period of about 2.1 seconds (that's the period of the "Sleep" function) independent of the main Clock Frequency. The Watchdog timeout is automatically cleared continuously by the operating system at all "normal" PICaxe clock frequencies, but with a Clock of 1MHz and lower there are certain instructions (for example those which have a timeout) that can take longer than 2 seconds to execute and the PICaxe may unexpectedly perform a Hard Reset.

Cheers, Alan.

 

[hippy]

I was going to say the same as AllyCat; that when running at 31kHz the 08M2 is probably being clocked by the more poorly calibrated internal oscillator so won't be very reliable and may drift over time which could lead to both sides losing synchronisation and data.

Bit-banging slow serial should work, but a better option is probably to use HSEROUT and HSERIN which can run down to quite low baud rates.

As far as I recall the baud rate is 'Fosc/(16*(N+1))' which with 4MHz and a baud rate divisor of 65535 would deliver 3 baud.

 

[charleswenzel]

Thanks for the explanations; I'll avoid 31 kHz. I assumed they were all simply divided down so I chose 31 kHz as an extreme example and I was only looking at sertxd (to save pins using the 08M2). 300 baud will work. I'll use HSERxxx if I use a chip with more pins; I didn't notice how slow the choices went and 300 baud is slow enough and I see how I could make that even lower by "lying" to the PicAXE about the clock frequency; 3 baud is pretty slow!

On another note, I noticed that the PicAXE can be pulled in frequency enough to move the IR remote control commands to the resonant frequency of ultrasonic transducers at 39 kHz. That would be a fun way to send a small amount of occasional data. The cheap Chinese remote control transmitter/receiver pairs are another option; just punch the button with the PicAXE. When the line goes high the receiver PicAXE starts timing and when the line goes low again the pulse width contains the voltage data. A second pulse could send a reference voltage for calibration and a third could identify the sender. I'm sending battery voltages once per night using a photocell to detect dusk and different delays (hours apart) for each sender. Obviously, I like nutty solutions.

Thanks again.

 

[papaof2]

"The cheap Chinese remote control transmitter/receiver pairs are another option; just punch the button with the PicAXE. When the line goes high the receiver PicAXE starts timing and when the line goes low again the pulse width contains the voltage data. A second pulse could send a reference voltage for calibration and a third could identify the sender. I'm sending battery voltages once per night using a photocell to detect dusk and different delays (hours apart) for each sender. Obviously, I like nutty solutions. "

Not nutty ;-) Sounds like something I might do if I had parts X, Y and Z and could see a way to use them - or if they were half the price of the "usual" way of doing things.

 

[charleswenzel]

I've abandoned the slow serial idea. This approach is really simple.
I'm building both ends today and I've decided to use the pulse width to send the individual digits instead of an analog value. I'm using a precise voltage regulator (LP2950A) and sending each digit will eliminate the effect of pulse width variations due to temperature. There's always a 1 at first; less than 10 volts is a really dead battery. The next digit is 1 to 5 and after the decimal another 10 (12.4 volts, for example). To send a "4" I'll send a pulse of, say, 400mS (probably faster but just to illustrate the idea). I just "press" channel 1, wait 400mS and press channel 2 with the receiver in the "only one of four" mode, like an old car radio's push-buttons. Channel 1 at the receiver outputs the pulses. So drift would have to drag that pulse below 350mS or over 450mS to change that digit. I'm also subtracting 10.9 volts from the 12 volts using a 6.9 and 4 volt precision reference in series with a resistor to ground. That way I get a full 4 volt swing on the PicAXE input for 11 to 15 volts on the battery. A PCB push-button connected to unused channel 4 allows the user to pair a receiver. (The instructions say to "press any button" to pair a transmitter and receiver after preparing the receiver by pushing that little white button several times.) So I actually need a button to press on the transmitter. Software is trivial: A short pulse will trigger an interrupt and three more pulses will be measured in the interrupt subroutine. One for ID (which car), the next two for the value (using pulsein). The transmit/receive pair are ridiculously inexpensive, about $2 for the pair.

 

[hippy]

Sounds like a good solution. If running at normal speeds when transmitting there should be very little error in the width of the pulse sent.

Another approach if there were more drift in operating frequency would be to send, say, a 100ms pulse as a reference which represents 100% of 10V, then you can send a second pulse which represents the percentage of the battery with respect to 10V. For example 5V would be 50ms, 10V is 100ms, 15V is 150ms, 20V is 200ms.

Drift usually happens slowly over time, and any error in pulse widths sent close together should be proportional. If the 10V reference pulse became 75ms a 15V pulse would be 112.5ms. Then 112.5 * 100 / 75 = 150, 15V.

That's just an idea, not saying you should do that.

Given that you are using what looks like dumb 433Mz modules they may not be as bandwidth limited as you thought they were and you probably could send serial up to 1200 baud or even higher.

Also, sending long pulses may actually be less reliable than sending serial. What tends to happen is that receiver 'loses lock' on the signal if it doesn't change over time so it may lose lock more on long pulses and gaps than it would with more frequently changing bits of serial bytes.

One thing to watch out for would be, that to get the receiver to initially lock, you may need to send a series of high and low pulses before every data transmission. That can sometimes be easier using serial.

The great thing about software projects is they can be changed if something doesn't work as well as expected. So I would go with what you propose and, if it turns out to be as reliable as hoped, you are done. If not you can contemplate doing it some other way.

 

[charleswenzel]

Yes, the data sheet says the pair can handle 10 kB. It sends a pretty sophisticated string so it's moving rather quickly to be able to do it 10,000 times a second. This T/R pair allows for four high/low lines so I don't need a continuous RF signal. A quick burst sets the receiver's output to #1 then after the pause another fast burst sets the output to #2. Making #2 high also makes #1 go low using what they call "interlock mode" so #1 will have the desired pulse width. I'm not using "inching" mode that would require the transmitter send a continuous stream of 1's during the pulse. The third mode lets each of the four outputs to be toggled independently but the problem is that there's no "zero all" command so there's the possibility of it getting out of sync. I "zero all" by selecting #2 and just not using that output. Maybe that can be a "ready" LED. There's yet another channel, #3, that I could use for a dome light alert or something similar. I'm "wasting" #4 simply to give me a pairing pushbutton, used only once! I suppose it's usable, too. At two bucks a pair I can waste channels!

 

[hippy]

At two bucks a pair I can waste channels!

Sounds excellent, a bit more than 'dumb 433MHz', and, as you say, a bargain at that price. Do you happen to have a link to share for the modules ?

 

[charleswenzel]

Sorry for the delay: https://www.amazon.com/dp/B06ZZ1Z6R7 look like the same ones I bought two years ago. I recall a pack of 5 and I have 5. Either the price increased or my memory is faulty! I'm eyeing the 10 pack. : )

 

[papaof2]

Two years? Price increase about 25% each year doesn't it? ;-)

Nice pair of TX/RX. If you need more than three, buy the 10 pack.

 

[hippy]

https://www.amazon.com/dp/B06ZZ1Z6R7

Thanks for the link. That makes it much clearer what you are doing - faking button presses which automatically get sent to the receiver. As you say it's effectively a four channel transmission medium, and no need to do anything but send 'pushed' or not to the transmitter as it handles sync and everything.

Pulse-width encoding should indeed work and be the easiest to implement. Slow serial should also work and it should even be possible to send data for the four channels simultaneosuly if one wanted to increase throughput..

 

[AllyCat]

Hi,

Personally, I would prefer to use a "raw" channel, but I recall very similar devices from Amazon.co.uk a few years ago. Not exactly the same, but here are apparently four very similar pairs for 11 UKP (US$14) directly from the UK site. Also, if you're persistent, you can (currently?) get free shipping on most items with no minimum order requirement, when you use their "Click and Collect" facility from a local Amazon pick-up location.

Cheers, Alan.