The game of Chinese Whispers or Telephone involves telling one person a sentence, having that person tell another person the same sentence, and continuing on until purple monkey dishwasher. For this year’s Arduino Day, [Mastro] was hanging out at Crunchlab with a bunch of Arduinos. What do you do with a bunch of Arduinos? Telephone with software serial.
The setup for this game is extremely simple – have one Arduino act as the master, listening for bits on the (hardware) serial port. This Arduino then sends those bits down a chain of Arduinos over the software serial port until it finally loops around to the master. The result is displayed in a terminal.
With only about a dozen Arduinos in this game of Telephone, [Mastro] did get a few transmission errors. That’s slightly surprising, as the code is only running at 1200 bps, but the point of this game isn’t to be completely accurate.
What Softserial version did he use? Since 1.6.1 there is a fix from mathijs which improves SoftSerial speed. Have you also tested with baud 9600 which might work better, even though its faster?
I tested only 1200bps, with the 1.5.8 ide. Updating all the firmwares is quite annoying, so I didn’t do any more tests… Maybe I can write a chinese whisper bootloader to update every arduino at once? At that error rate, it will be fun to see what gets into the last one! :P
Wait, what’s the source of these errors exactly?
Anything. Unshielded wire between units can pick up stray noise, random neutrino, and old fashioned gremlins to screw up the communication and cause error to crop up and get carried around.
Stray noise at a TTL level line capable of drive several dozens of milliamps? No I don’t think so Tim. And the random neutrinos would just as well crash the software as change the transmission, so that sounds as unlikely as gremlins.
I’d rather guess that it sucky connections in the jumper wires going from the Arduinos down to the solderless breadboard. The cheap (Chinese! ^_^ ) jumperwires with the tiny round pins at the end doesn’t make a good connection in the Arduino headers.
A poor connection that magically appears/disappears in a bit time, at exactly the same spot multiple times? Not terribly likely.
Especially because the power/ground pins need a much better connection, and it’s the same type of connection. So if the connections could fail, the Arduinos would be power cycling all the time.
Is CRC turned off here? Why isn’t it verifying the data?
That would defeat the purpose of the experiment.
OK, gremlins and neutrinos are amusing, but hopefully no one thinks either of those are a realistic cause.
Unshielded wire would almost never cause a bit error in a large-swing signal like this – especially not over such a short distance. I mean, a short bit of wire is a crappy antenna, and if you’ve got electric fields with what, 10 V/m around your workbench, I guarantee you’re going to have bigger problems than this (like the Arduino inputs dying). What is a much, much, much bigger problem is the fact that there’s no return for the transmit/receive signals, except through the breadboard.
Remember, current flows in a loop. Always. So when that serial line switches from “low” to “high”, that high-frequency current needs to return back to its source somehow: and the only path it has to do that is to go through the breadboard, back to the other Arduino: resulting in a very high impedance path, as well as a nice little loop antenna.
That being said… I think that’s probably not the actual problem here. I think the actual problem is probably clock skew between the Arduinos themselves.
Why do I say that? Because the bit errors are always in the same position – it’s always the 6th bit being clocked twice (so the MSB becomes equal to the 6th bit), which suggests mistiming when the bit is being sampled. This isn’t surprising, because it’s being done via the SoftwareSerial library (a soft UART), and pure soft UARTs (without even timer help) are really unreliable unless running entirely with interrupts disabled. At 1200 bps, that 7th bit comes almost a millisecond after the start bit. In fact, there are probably more errors than that, because the Arduino soft UART doesn’t check the stop bit, so it can’t see any framing errors.
Of course, it looks like the Arduino code itself isn’t doing anything else, so it’s a bit surprising even there. Soft UARTs, especially in C, can be really touchy, though, so who knows.
Right, I overlooked the fact that they are powered by jumper wires as well. So that’s probably not it.
At 1200bps the 7th bit would come about 6 mS after the start bit – not 1mS. And that would give a lot of leeway for any interrupts occurring during the character reception.
Not much of current is flowing if the pullups are turned off, the leakage current of an input pin is less than 1uA. But of course there is a capacitive part that needs to be (dis)charged at level change so briefly the current will be much higher.
The NewSoftSerial that has been “native in the core” since Arduino 1.0 actually seems to to be interrupt driven according to the dox, but I haven’t checked if that is a portchange-interrupt for the startbit only or if it’s using a timer interrupt for the bit-sampling.
“And that would give a lot of leeway for any interrupts occurring during the character reception.”
Depends on how the timing is done. Software loop timing *aggregates* errors over the entire character reception, so slower bit rates become harder and harder.
Timer-based bit timing obviously doesn’t care about that.
“Not much of current is flowing if the pullups are turned off, the leakage current of an input pin is less than 1uA. ”
The leakage current is completely pointless – for one thing, it’s DC, so it doesn’t care about impedance, only resistance. Plus it’s tiny. The *switching* current, however, is huge – it’s the maximum drive of the chip, usually around ~10-12 mA. And it’s AC, with components well up in the 100 MHz range, so the impedance of the line dominates over the resistance. That’s the “briefly the current will be much higher” part, and sadly that “briefly” bit is what predominantly causes problems.
” but I haven’t checked if that is a portchange-interrupt for the startbit only”
That’s what it is. The delays are hardcoded and software-loop timed – however, the software-loop happens in the interrupt handler, so it should be immune to incoming interrupts, except in when the start bit arrives.
It’d be interesting to see how bad the ringing is on the receive/transmit lines – I can’t imagine it could contribute significantly. The bit rate is just too slow – there’s no way a 100 kHz frequency component is contributing. So it’s *got* to be coming from clock skew, due to the fact that NewSoftSerial doesn’t oversample.
So with that hypothesis, the prediction would be that if you changed NewSoftSerial to actually look for framing errors, you’d see many more framing errors than data errors, since the stop bit is later.
Switching out the SoftwareSerial for a native hardware serial lines would certainly narrow down the search field significantly. I suspect that it’s timing issues in the serial library but I do find it surprising to see that many errors at 1200 baud.
I wasn’t quite sure from the terminal, but is it possible to determine if there’s a particular unit that’s causing the errors, or if it’s random?
Non ti passa proprio un cazzo :)
I’d say this is how Skynet comes on line. Dude playing with his arudiunos and serial com errors. The right bits just happen by chance and it becomes sentient… You know the rest of the story.
No, arduinos due both to their isolation from the internet and their low processing power will be immune to sentience. The real culprit will be the various security agencies hardware backdoors. A simple virus will exponentially expand through these backdoors taking control of botnets and the stock market repurposing software like stuxnet to become completely unstoppable.
Well, but that’s TWELVE arduinos we’re talking about here! And they’re connected to a computer!!
+1 for the POI reference. But don’t worry, I’m sure Aurora will kick Samaritan’s butt.
“Chinese Whispers”? Is that really ok? I’ve never heard this term before, but I suspect it’s not the most PC.
The term has been around since the 60s at least. In the USA it is usually called telephone, but apparently Chinese whispers originated in the UK (It was called Russian Scandal before that). I don’t particularly care about PC. I think it is dumb to take offense to something that is not intended (especially when you do not belong to the potentially offendable group). Funny story, there was a university around where I live that was pushing to ban the school song because it was sexist towards women, it turned out when they actually surveyed the school there was not a single female that took offence to the song and it was all men who were being too PC sensitive. I thought it was hilarious.
The important part of phrases like “Chinese Whisper” (which we always called “the telephone/telegraph game”), or the southern USA thing of “Chinese Fire Drill” at a stop light, is to recognize the reason they are offensive. The drive to be PC becomes unimportant when you have the empathy to realize why someone else would be offended.
No, the anecdote that no one has ever told you it offended them doesn’t matter. Some one may not speak up because they don’t want to cause a problem (and possibly reinforce a stereotype) or because they didn’t hear you. Empathy is all it takes.
Ive never heard it before either, nor do I care. you know what else i dont care for? The term Politically Correct, it sounds offensive.
As wikipedia says, and as I wrote in the blog post: “in the video, I call the game “chinese whisper”. That was the first google result for the translation from italian, but after reading more I see that “Today, the name “Chinese whispers” is said by some to be considered offensive.“. Sorry for that chinese friends, but to be honest I must say that, having been in China recently, I kinda agree that “Using the phrase “Chinese whispers” suggested a belief that the Chinese language itself is not understandable”. :) “
All languages are hard to understand if you don’t study them well and live around them constantly. I even find English spoken with certain accents to be impossible to understand, and it’s my native language. Tonal languages are very rough if your native tongue isn’t tonal.
Yeah, I find it weird and sad that HaD would throw that in an article title given their international audience. I really can’t see that name meaning anything other than insinuating that chinese people are all liars :/ Especially since the name apparently dates back to the sixties :P
Also really gross are the people who are anti-PC for anti-PC’s sake. I bet you they would feel quite differently if they were the butt of the joke.
As someone who’s the butt of the joke, nope.
Call me Gweilo, call me Honky, call me Gaijin, call me a WASP, I don’t care, stick it up your PC knee jerk … and get over it, please? Can’t take a joke, …. ’em.
I’ve always thought the terms Chinese [fill in blank] are used to describe things that are too long or difficult to describe otherwise. For instance, Chinese fire drill, Chinese (finger) puzzle, etc. A bit lazy, perhaps, but not necessarily offensive. Some are considered offensive these days, though, like Chinese ace, Chinese home run, etc. because of their connotations with ineptness, but Chinese whisper isn’t, IMHO.
Anyhow, when I read the title I thought this article is another one on the ongoing battle between the two Arduino camps. Perhaps a well-meaning statement said by one side that was lost in translation or has been completely misunderstood.
The Grape-vine game is a more fitting and known term IMO.
Use the internal RC oscillator (instead of crystal) and periodically updating the OSCCAL (Oscillator Calibration Register) with a pseudo random sequence. That should introduce a mismatch of the CPU frequencies between senders and receivers and introduce higher receive error rate.
Yeah, this is why soft UARTs, especially sleazy soft UARTs like the Arduino’s (even the NewSoftSerial), are a pain. Most of them are very minimalistic.
A hardware UART, especially at this bit rate where you can oversample easily, would probably never have a single bit error in the lifetime of the hardware.
I would agree that the more interesting question is why/how there are so many errors.
A consistent pattern of “the sixth bit being clocked twice” as noted by Pat certainly suggests timing rather than noise. I wouldn’t be surprised if such consistent errors always occurred on one particular link – it would be interesting to modify the firmware such that you could trace it down. Or just move the jumpers around, tapping into the output of successive ardu’s until you start seeing the errors. OTOH, if the errors come from multiple ardu’s, that would be suggestive too.
I wonder if it could be cumulative errors from the millisecond timer, that sometimes catch up to you on the that bit?
This seems a completely wrong interpretation of chinese whispers, since the errors don’t propagate at all, you need to send in a sentence and have it loop including more and more errors. And limit the available characters to ASCII to keep it readable regardless of the errors.
So some poorly written Arduino code produces errors.
Why is this surprising?