Boxed MCU with RS-232 Port

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.  

-- 

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> 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:

https://www.cnx-software.com/2023/01/17/edatec-cm4-sensing-industrial-computer-offers-can-bus-rs485-and-rs232-interfaces/

Note that most of the boxed computers on that blog are quite powerful,
more than you need for this:

https://www.cnx-software.com/news/industrial

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?

On Tuesday, January 17, 2023 at 3:31:21 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > 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: 
> 
> https://www.cnx-software.com/2023/01/17/edatec-cm4-sensing-industrial-computer-offers-can-bus-rs485-and-rs232-interfaces/ 
> 
> Note that most of the boxed computers on that blog are quite powerful, 
> more than you need for this: 
> 
> https://www.cnx-software.com/news/industrial 

Yes, way overkill.  I think I said the initial units use the Arduino nano.  No OS required, and in fact is a liability.  


> You could try a more general web search for "industrial embedded 
> computer" if that is the sort of thing you want. 

Yes, and I get the sort of things you link to above.  


> 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? 

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. 
https://www.brainboxes.com/product/usb-to-serial/usb/us-257
https://www.brainboxes.com/product/ethernet-to-serial/db9/es-257
Right 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.  


> 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? 

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. 


> Regarding the programming, if it is just as you describe, there is not 
> much to it, I would have thought. 

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. 


> 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?

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.  

Thanks for your reply. 

-- 

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Yes, way overkill.  I think I said the initial units use the Arduino
> nano.  No OS required, and in fact is a liability.

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.

> 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.

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?

> Here's what I would like to use. 
> https://www.brainboxes.com/product/usb-to-serial/usb/us-257

Those look nice.  I will keep looking around / asking around.

> There is a ton of idle time to send the headers between the 50 char
> messages.

Ah right, I had missed or forgotten that there was just one message per
second.  Yes, you are fine.

> 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.

Arduino code is C++ with some special libraries and light preprocessing,
so it shouldn't be too big a deal to hack it.

> 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....

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?

> I'm not even sure why the data is being buffered, it could be sent
> through one character at a time...

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.

> If I wasn't up to my ears, I would take this on.  But I am, so I
> can't.

Understandable ;).

On Tuesday, January 17, 2023 at 5:08:01 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > Yes, way overkill. I think I said the initial units use the Arduino 
> > nano. No OS required, and in fact is a liability.
> 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.
> > 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.
> 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?

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. 


> > Here's what I would like to use. 
> > https://www.brainboxes.com/product/usb-to-serial/usb/us-257
> Those look nice. I will keep looking around / asking around.
> > There is a ton of idle time to send the headers between the 50 char 
> > messages.
> Ah right, I had missed or forgotten that there was just one message per 
> second. Yes, you are fine.
> > 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.
> Arduino code is C++ with some special libraries and light preprocessing, 
> so it shouldn't be too big a deal to hack it.
> > 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.... 
> 
> 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. 

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. 


> 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?

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. 


> > I'm not even sure why the data is being buffered, it could be sent
> > through one character at a time... 
> 
> If this thing is susceptible to later feature creep, the buffering might 
> make things easier. 

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. 


> 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. 

The problem follows certain units.  I don't know how they did testing, but the units that work, work. 


> > If I wasn't up to my ears, I would take this on. But I am, so I 
> > can't.
> Understandable ;).

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. 

Thanks for your insights. 

-- 

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Once the error is observed, a power cycle is required to fix it.  It's
> not a one time glitch.

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.

> 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.

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.

> The real problem is not the glitch, but that the failure remains until
> the translator is reset.

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?

> 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?

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.

> 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.

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.

On Tuesday, January 17, 2023 at 6:04:44 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > Once the error is observed, a power cycle is required to fix it. It's 
> > not a one time glitch.
> 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.

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. 


> > 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.
> 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.

"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. 


> > The real problem is not the glitch, but that the failure remains until 
> > the translator is reset.
> 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?
> > 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?
> 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.

We have units that work.  We have units that fail.  I don't know what we would learn from using a laptop. 


> > 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.
> 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.

If pigs had wings, they would fly.  The only trouble is, they don't have wings. 

-- 

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> "Desparate"?  They just don't want to mess with the box that is
> receiving the data, not yet anyway.

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.

> We have units that work.  We have units that fail.  I don't know what
> we would learn from using a laptop.

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:

https://www.ebay.com/itm/125720309804

They are cheap and plentiful, but maybe not the right look, as it were.

> If pigs had wings, they would fly.  The only trouble is, they don't
> have wings.

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.

On Tuesday, January 17, 2023 at 7:32:51 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > "Desparate"? They just don't want to mess with the box that is 
> > receiving the data, not yet anyway.
> 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.
> > We have units that work. We have units that fail. I don't know what 
> > we would learn from using a laptop.
> 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. 

???  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. 


> Someone on irc suggested using thin clients from ebay: 
> 
> https://www.ebay.com/itm/125720309804 
> 
> They are cheap and plentiful, but maybe not the right look, as it were.
> > If pigs had wings, they would fly. The only trouble is, they don't 
> > have wings.
> 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 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. 

-- 

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> 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.

Ok, same idea.

> You mean a laptop with an oscilloscope dongle?

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.