08m2 serin bug

[bpowell]

Very cool...thanks Goeytex!

 

[Jeremy Harris]

Thanks Westaust55...I'd already been down this road, and those links only further reinforce my idea that in Serial comms such as the PICAXE is using (only two possible bit states, 1 and 0) bit-rate = baud-rate.

Yes and no.

The encoding system used can result in variations, too, as strictly speaking the baud rate is determined from the number of characters transmitted in a given period of time and the average number of bits per character, and different encoding methods can mean there are differences.

Also, because traditionally the baud rate was measured from the starting edge of the start bit (a falling edge in conventional serial comms) to the centre of the last bit in the character, divided by the total number of bits in the character (including start and stop bits) there can be a variation from bit rate, where a consistent edge is used to make the measurement.

As I alluded to before, this all goes back to the way the RS232 standard was derived and the old Baudot encoding system that started it all. The system worked by using the edge of the first start bit to de-clutch the transmitter drum (so timing starts on an edge), with the detection window of the receiver set to a time interval that should correspond to the centre of each bit. The result is that the time from the edge of the start bit to the centre of the detection window can be longer (by half a bit width) than the time between detection windows.

Technically, therefore, baud rate and bit rate can be different. In practice, given the way that things have developed this need not be the case, as you say. If you want to ensure universal compatibility using serial comms, it makes sense to ensure that the tolerance on timing is sufficiently broad to cover both the "in spec" standard (start bit edge to initial data bit centre) and variations where detection windows are all the same width. Also worth noting that the RS232 (or whatever name it has now) standard isn't that tight, and allows a fair bit of leeway (it also refers to voltage levels that aren't now that common for the sort of serial comms we tend to use).

 

[hippy]

Thanks Westaust55...I'd already been down this road, and those links only further reinforce my idea that in Serial comms such as the PICAXE is using (only two possible bit states, 1 and 0) bit-rate = baud-rate.

For the digital high/low signalling used there are only two states and bit rate = baud rate.

However, imagine we are not sending over wire but have a person on one side of a chasm communicating with another on the other side. They could send digital high/low signals by using a single flag, raising or lowering it. The receiver can write down what they see on a regular basis, just like an electronic system does, then decode that into whatever it means.

Give the sender two flags and they can transmit two bits of information in the same period of time it previously took to send one bit.

If you allow the flag/flags to be at intermediate positions rather than just fully raised or lowered you can send even more bits in one go.

In the electronic world you can send more than one bit per period by using an analogue signal or by sending tones which aren't constrained to just being high/low, on/off, present/not present.

 

[SAborn]

However, imagine we are not sending over wire but have a person on one side of a chasm communicating with another on the other side.

Im just glade we dont still use lantens and morse code to communicate between devices / locations nowdays.

The internet would be rather slow if that was the case, with server downtimes to refuel the lanten, although you might say data transfer would be at light speed.

 

[inglewoodpete]

Im just glade we dont still use lantens and morse code to communicate between devices / locations nowdays.

The internet would be rather slow if that was the case, with server downtimes to refuel the lanten, although you might say data transfer would be at light speed.

Don't optical fibre communications use lanterns flashing at one end of each link?

 

[SAborn]

But do they still use kerosene to power the lantens for OFC.

 

[mrburnette]

I used 2 Picaxe Chips as you suggested. <deleted...>

I don't get around these PICAXE parts much anymore, but in the past I had issues with two PICAXE chips 'talking serial' to each other, one was a 20X2... cannot remember now what the other one was... SO IT IS GOOD that RevEd is saying the new 20X2 firmware cleans up timing.

Here is my history on the subject: Using a PICAXE with a PC has never been a problem for me. Using two PICAXE to communicate over software-serial has been an issue for me. I am absolutely certain that Goeytex tests of timing are accurate as I have used my own NIST traceable scope to verify software-serial timing deviations from perfect. "Acceptable" is a word that may or may not work for you depending on how you design your project. There are also "serial timing" concerns in the Arduino community, but with most Arduino implementations using external crystals for a timebase, many simply use the hardware serial port rather than software serial.

Bottom line, software serial timing issues are not specific to PICAXE. I2C, SPI, or USART are always preferable choices.

- Ray