Serial port - odd behaviour

Targets Raspberry Pi
1

Hi,

I have two devices that I’m reading on serial ports (FTDI usb2serial) connected to a pi 2 running from the mains using the correct 2a supply.
and adding the data to a listbox a row at a time
One ( weighing scale) is working perfectly well, The other (an RFID reader) is receiving data with bits missing and sometimes what look like control chars in the data.

This exact code runs perfectly with these exact devices when plugged into my mac instead.
I know the baud etc are correct,
I can connect with screen /dev/ttyUSBx 9600 and it works perfectly
If i switch the ports the behaviour always follows the RFID reader, it never happens on the scale!

Since i cant remote debug on the pi, i cant step into the dataavailable event and see whats happening though

any ideas?

2

If possible please, try to connect these USB serial adapters using an external USB hub with a power supply.
Maybe the available current on the Raspberry’s USB ports isn’t enough.

3

Same thing happened to me here.
How are you setting the baud rate?

4

i didn’t actually set it, it was on 9600 when i dragged it onto the window, so i just left it at that.
I will read that thread and see if i can find a solution. Its very strange though isn’t it?

5

Hi,
Not sure if you are knowledgeable about how an RFID reader works, I apologise if so, but it is basically a radio transmitter that sends pulses of RF to the tag which, depending on its type, returns a radio signal or interrupts the radio energy and causes a sympathetic response in the reader.

The passive type readers are quite powerful and it is perfectly possible that the current used is, at its peak, causing an issue with the power supply, or more likely the actual RF energy is upsetting the PI hardware, which is not shielded in any way normally.

I expect the main computer is far more able to filter out radio interference than the PI is.

I use the PI on a current major project and its serial port reading is no different in my experience to all the other devices it is tested upon, which leads me to think its an external influence.

generally with strange characters being received when not expected it is the incoming stream being corrupted, usually by timing, bit if there is a drop in voltage or RF in the cables I would expect to see what you describe.

try a powered hub for the reader, move it as far away as possible from the PI, shield the PI etc, just to see what is going on, I would be interested in your findings!

Regards.

6

Hi @Mark Carlton

Interesting info. wouldn’t the fact that it reads correctly on the pi, when using screen , mean that external influences are not at play ?

Btw, it’s an industrial unit with its own power supply.
I suppose it could be back feeding interference into the mains, but the pi is using a transformer brick, which I think should negate that.

The antenna in this test is just a small loop to allow me to read tags at close range, but in the finished design will be a panel with a larger field.

7

Any cable plugged into the PI will act as an aerial for any airborne interference, RF will go everywhere and have an effect on anything.
the same piece of wire bent in a different shape can make things worse or better, it is very difficult to deal with.
standard practice is to place ferrite rings or clamps on ALL cables connected to the device having the issue, at the closest point to the effected device.

an example is this:-
Ferrite Clamp

these devices will reduce the interference on the cable, which is why you put then as close to the device socket as possible, but not that seen by the device its self that enters the circuit board on the PCB tracks.

Adding or removing connected parts to the PI can have positive or negative effects, it could be that the interference is nullified when the display is plugged in because the interference is getting in on that port, without a connection it is high impedance making it much more susceptible, plugging the display in will lower the connectors impedance and stop the interference, that goes the same for all sockets on any device.

All tracks on a PCB are aerials and will happily act as such unless you protect them.

This subject is a whole science in its self, I have put several product through US and EU compliance testing and am a Radio Amateur enjoying the benefits of radio.
Compliance testing is not only about the interference the device its self causes to the outside world, but also how the device its self is effected by external interference.

Give RF half a chance and it can kill a product dead unfortunately.

I personally would not deploy a PI in any commercial environment without it being in a metal enclosure, the PI is not designed, at its bare board level, to be used directly in any commercial environment without the standard precautions used on any product deployed in the same environment.

Even if you find some other cause for the issue, the comments above are the absolute minimum to consider when employing any device in an commercial environment, it is possible it will work when you test it, but if something changes when you leave and things stop working, it can be very hard to track down.

If you are going to use it with a large filed aerial then you must take some serious steps to mitigate the issues that will result from RF from that device, or any other , such as a mobile phone, wifi, POS terminal, two way radio, microwaves, bluetooth scanner, etc.

I have made a living out of rebuilding systems not designed initially with these things in mind!

I am currently working on a commercial product using the PI as its main component with serial ports and an official PI display.

8

hi Mark,

Im not planning on using the Pi in the final solution, i’m just prototyping what i want, to hand it to the microcontroller guys who will then make that up. its much easier to mock it up as a working system to go with the spec.

to be honest, i can use my mac for that, but i thought it would be fun to try the pi as it seemed to be designed for such projects - perhaps not!

i do have ferrite clamps on the cables at the reader end, but not at the pi end.

what i still don’t get though, is that the terminal program I’m using on the pi (‘screen’) is not seeing this effect at all, which leads me to believe its an issue with Xojo.

9

I think you can dismiss Xojo totally, it has no idea what the source of the data is, my own solution is entirely Xojo built, including the serial receive app in the PI, the same code on my Mac, in Linux and several windows machines around the world all work flawlessly with the same code.

Whatever is seen by Xojo I would bet is correct, but disturbed in some way before it sees it therefore it is interpreted as shown to you.

have you got screenshots of real data and the same corrupted data, its possible that a clue can be seen from that, but it must be aligned correctly on a byte by byte basis.

10

How are you reading in code, do you have the right encoding (if required?)

11

Have you tried to toggle CTS and DTR? serial.DTR and serial.CTS on and off in Xojo? I have experienced data corruption with some devices that do not support those control lines while they are enabled in Xojo serial control.

For one device, setting DTR to false solved the corruption issue.

Cheers