The unit only really needs one serial port, but it is more convenient to have two connectors, so I guess it needs to ports. One port will only receive and the other only transmit, no handshaking.
The function is pretty simple. A sensor sends a line of about 50 chars, at 9,600 bps, once per second. This box counts 20 lines and adds a header. So nothing fancy is required of the MCU. There are parameters set when starting operation.
The main thing I'm having trouble finding, is this needs to be in a box as a unit, not a board and a box to be assembled. Google hasn't been much help returning all sorts of things that aren't useful.
Anyone know of such a box? The programming might be contracted out, if you are interested. There's a prototype using an Arduino nano, but some of them are flaky and it would not hurt to start over from scratch.
There's about a gazillion industrial computers that do this, though they are probably overkill and more expensive than one would prefer. This one is on the front page of cnx-software right now:
formatting link
Note that most of the boxed computers on that blog are quite powerful, more than you need for this:
formatting link
You could try a more general web search for "industrial embedded computer" if that is the sort of thing you want. Do you need the box to come from a real manufacturer with customer support? Is the idea to deploy a moderate number of these, say dozens? A much larger number? Or is it basically a one-off?
If characters are coming in at the full speed of the 9600 bps port, and going out at the same speed, and more characters are going out than coming in (because of the headers being added), how is this supposed to work with no flow control?
Regarding the programming, if it is just as you describe, there is not much to it, I would have thought.
If there is only one input port to this box, why use a box at all, rather than have the sensor emit the header every 20 lines?
Yes, way overkill. I think I said the initial units use the Arduino nano. No OS required, and in fact is a liability.
Yes, and I get the sort of things you link to above.
I think they have built a dozen now. They expect to build a few more before the modify the receiver of the data to handle this function. They are making this with an Arduino nano and a small custom board for the RS-232 converter, in a 3d printed box. All of that is fine I expect. But they are having this problem.
Here's what I would like to use.
formatting link
size, right case. But they are not a computer as such, they're USB or Ethernet based serial port adapters. I've written to them to see if this unit can be programmed by the user.
You mean, how would it work *with* flow control, right? The data is coming in, 9,600 bps, 50 chars per second. There is a ton of idle time to send the headers between the 50 char messages.
There's always more than meets the eye. I looked at the code and although it's Arduino code, it is enough like C that I can tell it's missing a few things. One is, the files I have are line delimited by the DOS convention, /r/n. The program counts lines by checking for /r, ignoring /n. I don't know if that would cause any problems, but if the /r is missed from data corruption, the character buffer would likely overflow, causing who knows what harm. The character count should be checked for bounds. I'm not even sure why the data is being buffered, it could be sent through one character at a time, simply monitoring for the end of line.
We don't control the sensor. It used to send a periodic header. They changed to a new model or an upgrade, or something else which means the header is no longer sent.
If I wasn't up to my ears, I would take this on. But I am, so I can't. But that may change.
The OS won't hurt, but maybe it won't help much if the thing is this simple. I can say I worked on a much fancier gadget like this using an ARM Linux board (it intercepted and modified the data stream between a POS terminal and a receipt printer, doing full duplex comms on both sides while also getting data from the internet) and it worked fine using the on-board 16550-style UARTs.
Hmm, I wonder if it can be diagnosed, if they are ok keeping on using the same hardware. Any idea what was going wrong? Flaky hardware? Underpowered RS232 ports?
Those look nice. I will keep looking around / asking around.
Ah right, I had missed or forgotten that there was just one message per second. Yes, you are fine.
Arduino code is C++ with some special libraries and light preprocessing, so it shouldn't be too big a deal to hack it.
Fair enough, yes, the program should check for various kinds of errors.
Is it disastrous if an error results in some kind of alert that temporarily stops operation? The idea is to deploy something that passes reasonable testing, possibly hit a few unexpected error conditions during initial production, fix those, and hopefully be reliable afterwards, but have it not be catastrophic if something goes wrong after a long period.
What do you want to have happen in case of data corruption anyway? Do the messages have checksums and should the pass-through box check them?
If this thing is susceptible to later feature creep, the buffering might make things easier.
It seems to me that if you have another person involved with the programming, that person should be close to the customer site in order to diagnose issues that might come up with the installed systems. Or at least, they should have real sensor hardware that they can test with.
I don't know. The original guy who designed this is a bit busy. Because the problem is associated with some specific units, it's not terribly likely to be a coding issue. But who knows? Once the error is observed, a power cycle is required to fix it. It's not a one time glitch.
This is actually a patch added when the sensor was changed to an updated model which no longer outputs the same format or the headers. It is likely to be dealt with by a change in the device that receives the reformatted data... at some point.
I don't know. I think Checksums are overkill and just not appropriate. There's no one to add or check the checksums. I believe this is data that is simply being logged. The real problem is not the glitch, but that the failure remains until the translator is reset.
In talking to someone else, I remembered that the date and time formats are changed as well, so that's why the message is buffered.
The problem follows certain units. I don't know how they did testing, but the units that work, work.
Anyone else have taller ears? lol
I'd be happy with a solid CPU in a good box. The current units are hand wired, so who knows how well they are made? This is the problem when one person designs something, then another person has to make it work. You never know where the bodies are buried.
Gack, yeah. I had been thinking, this isn't my area, but my understanding is that the RS232 electrical spec requires voltages that are somewhat above TTL logic levels, and that various crappy devices skimp on these voltages and mostly work anyway. So that is a thing to suspect if a home-brew RS232 device is acting flaky. It could be that the device at the other end expects those voltages to be closer to the real spec.
Can I ask about the device or computer that is receiving this data? Does that have software of its own that can be modified? Adding a hardware box just to deal with a software protocol change seems pretty desperate.
How about including a WDT that resets the circuit? Is it possible to tell if the CPU is even still running when the device locks up?
As a test, you could put in a laptop with an FTDI cable and see if that is able to keep the system happy. That's how we tested all our stuff with the POS interception thing that I mentioned.
Yes, that's why getting a remote contractor involved for something this simple sounds like more trouble than it's worth. It's much more hassle than if the person is already there in your shop and is familiar with the product.
They used a MAX3232CPE which generates it's own voltages using switched capacitor voltage boost. I wanted to check the values of the caps. Seems the have different minimum values depending on the Vcc voltage. But they are not in the BoM. I'll ask about this. It could easily be the cause of the problem.
"Desparate"? They just don't want to mess with the box that is receiving the data, not yet anyway. This was supposed to be an easy way to get it working with a minimum of fuss. It just didn't work out.
We have units that work. We have units that fail. I don't know what we would learn from using a laptop.
If pigs had wings, they would fly. The only trouble is, they don't have wings.
Well, desperate in the sense that modifying software is usually easier than deploying and maintaining another physical computer, but I guess it depends on how hard it is to mess with that box.
If the laptop worked reliably it would show that the basic FTDI interface was sufficient. It would also allow spotting issues with the incoming data, etc.
Someone on irc suggested using thin clients from ebay:
formatting link
They are cheap and plentiful, but maybe not the right look, as it were.
I just worry that if this is all special purpose hardware at the endpoints, making the gizmo work may involve checking levels with an oscilloscope and stuff like that, rather than being a pure software matter. The laptop could help test that theory.
??? You seem to be missing the fact that there are existing units that do the job without a problem. The problem is linked to specific units. There's nothing to learn from using a laptop. I believe they have used a PC running Putty to capture data on the serial ports.
You are looking where the light is better, in spite of the fact we know the problems not there.
You mean a laptop with an oscilloscope dongle? A digital measurement of the RS232 signals by a PC is not of much use if you don't know where the thresholds are.
I mean an scope with analog inputs to check voltages, timings, noise, etc. You have boxes that work and boxes that mostly work. What makes the boxes different from one another? It sounds like something somewhere is marginal.
I hope this extreme an approach is not needed, but if custom hardware is involved and you have the final responsibility of getting everything working, you have to be ready for whatever it might take.
I remember on the POS project, we had some kind of multi-channel logic analyzer for this purpose, though I don't remember using it. We also had some hacked up serial cables that let us monitor the traffic between two devices by tapping the TX and RX pins and bringing them out to a third DB9 plug that we connected to another computer. Those cables were very useful. I think I can figure out how they worked, but I've been wanting to ask the guy who built them, just to be sure.
If you know anything about RS-232, you would know that it has margin on top of margin preventing marginal issues. The spec is that the voltages between +3V and -3V at the input of the receiver, while the driver is specified to drive at least ±5V. There's 2V margin. Then there's the fact that the actual threshold of the receiver is around 0.7V. I measured this once, but I don't recall the exact number, it might be more like 1.0V. The point is, there's another 2V margin.
I've asked for the values of the caps on the MAX3232 chip. If one of those is out of spec, it could impact the drive capability.
I don't have the units, so I can't put a scope on anything.
Not sure how a logic analyzer would help. That's for digital signals. You are talking about an analog issue.
I would like to find some hardware appropriate to the task. I can't even find an Arduino compatible board that has an RS-232 level shifter chip on the board. Everyone just copies the same design. I also can't find any lower end MCU in an enclosure with two serial ports. Everything I've found is a hulking x86 compatible gadget with all sorts of high end interfaces, and only one serial port if any. I guess that's why the guy made his own box. But there are tons of RS-232 interface boards to use with the Arduino. I guess the fact that they have the DB-9 connector is a problem.
The logic analyzer for the POS thing was probably for debugging timing problems. I think it was able to timestamp more accurately than our software hack could. You are right that it wouldn't handle analog issues.
There's a number of ARM boards with RS232 but that's just x86 in minuature, perhaps. Here is one with two RS232's, and again way more other stuff than you want:
formatting link
Actually it looks like they have (had?) an AVR board with RS232 (single port, meh). It is out of stock though, and (who knows) maybe discontinued:
formatting link
Were you thinking of using a single port and splitting out the TX and RX wires? That is a little bit too hacky imho.
The company is in Bulgaria but some of their stuff is stocked by Digikey, so you could check there.
Also maybe this?
formatting link
Claims to have two uart ports and rs232 tranceiver chip, but uses JST-like connectors rather than DB9. Same processor as the generic ARM Bluepill though, and no extra ports other than USB.
Hmm, this one has two DB9's:
formatting link
Anyway you can find other stuff there too.
I think stuff these days tends to use USB, which is its own can of worms, but it is easy to get USB to serial converter cables.
I guess I'm getting tired. If I'm buying a board, one serial port is fine. UARTs are two separate devices, a transmitter and a receiver. They are not connected other than sharing the same bit rate and other format configuration, perhaps. The only reason for wanting two serial ports would be when buying a box level product, since external wiring is simpler with two cables, rather than a Y cable
ARM boards would be fine, but I'm not making a box, so I guess this will be someone else's problem.
I'm very surprised Digikey and Mouser don't carry a box device like this. They have lots of embedded computers, but they are like a PC in a small case. Some are like rPi's, with ARM processors, but still too messy dealing with a complex processor and an OS.
It is weird, there must be something like that, but product search everywhere is terrible. I notice there is a new stackexchange for hardware recommendations:
formatting link
It doesn't look that great, but who knows.
If you can power it up and get a linux shell and run gcc, that is pretty easy to deal with. You don't have to worry about the amount of software underneath the shell prompt, you don't have to worry about UART device registers since the OS handles that, etc. I do understand that it is hardware overkill despite this.
That's not really true. One way of making an MCU robust, is to reboot it periodically. If it can reboot in less than a second, it can do this job while invisibly rebooting. It takes significant time to reboot an rPi. There's ZERO reason to bother with more complex hardware that still doesn't have RS-232 I/Os or a case.
No, no reason to worry about any of that, because an OS is not going to be in the device.
So have it auto-reboot at night. More seriously, the thing that fails the most on Rpi-style boards is the SD card. If you have a board that doesn't use an SD card, it can be pretty robust.
Of course the Arduino library is sort of an OS, if you use it.
I still worry a little about whatever is making your existing box fail. If you can isolate it to those capacitors or whatever it was, that is great. Otherwise maybe you have to be ready for the possibility of installing a ready-made box with properly working RS232 ports and still finding that it occasionally fails the same way.
Regarding the boxed microcomputer, someone on the Forth group might know of a suitable product? It's the type of thing they might be using.
You mean "\r" and "\n" here - programming is fussy about the details!
When counting line endings, I usually accept either character, and if "\r" is received then a following "\n" is ignored (and vice versa - some people get things wrong and send "\n\r").
The standard for DOS is "\r\n", the standard for *nix is "\n", and the standard for old Macs is "\r". I would not be happy simply counting "\r" characters unless I was sure the incoming data always used carriage returns - if I were to pick just one character, it would be "\n". But checking for either is best.
Data corruption is always something you have to consider. Sometimes you can't do much about it, and will just pass on the mess - or skip it until the data looks good again. But you at least want to make sure there are no buffer overflows if a line ending is missed!
That was my first thought as well so I looked it up to double check. The MAX3232CPE is 0.1uF across the board so far as I can see. You do hit problems with MAX232's - the original needed 1uF caps but the MAX232A and several alternate manufacturers specify 0.1uF as a minimum. Problems can arise if a MAX232 is put in place of one of the alternatives but with the 3232 I'd expect people to get it right.
OTOH the 3232 is a 3.3V compatible part. One thing they all have in common is the charge pumps are a bit weedy in terms of voltage, aiming for +/-5.5V regardless of supply voltage. That's within current specs but the RS232 minimum voltages have dropped over the years, I suppose it's possible the port of the receiver is an older design. In any case it doesn't leave particularly large headroom for losses. Do you know if the protocol translator is on a 3.3v or 5v supply? If the latter a MAX232A (note the A) is a drop-in replacement with typical +/-10V drive. If 3.3V a booster of some form will eliminate low voltage as an issue - in terms of off the shelf hardware that would probably be a pair of RS232<>RS422 line extenders back to back.
The data sheet I saw has a table of minimum capacitance for three Vcc ranges, 3.3V, 5V and 3.3 to 5V approximately. Only 3.3V was 0.1 uF on all caps. The others were larger on at least one cap. Table 9-1 on page 12.
You mean the RS-232 (TIA/EIAI) specification has changed? I have not seen this.
5V supply. I don't know why you are talking about the MAX232. I've said "MAX3232CPE" several times.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.