Has anybody worked with these? I'm having trouble finding any information
about serial output formats. I've got this far: I've configured it for
UDP, and sent a UDP packet with a string of ASCII alphanumeric characters
as payload (using the Python socket module). The serial output then
provides
* a byte 0x02 -- perhaps ASCII STX, perhaps not
* 4 bytes that could be the IP address of the sending host in big-endian
format
* a byte 0x00
* a byte containing the number of characters in the payload string
* the payload string.
I haven't seen anything on the web site or the documentation CD that
confirms or denies these assumptions. In the short term, I guess I can
keep on developing with what I think I've got.
The guy who did the USB variant of our product used an FTDI chip, and
devised a protocol that put an unequivocal frame mark in the serial stream,
and used a system of escapes to guarantee that no data could be mistaken
for a frame mark. I don't see any signs of this in the XPort output I've
got so far.
Mel.
Experience with Lantronix XPort Internet-Protocol-to-serial device?
Started by ●September 17, 2008
Reply by ●September 17, 20082008-09-17
On Wed, 17 Sep 2008 12:15:01 -0400, Mel <mwilson@the-wire.com> wrote:>Has anybody worked with these?Only played with one out of curiousity er ahh, I mean that I evaluated a development unit with an eye towards possible future use.> I'm having trouble finding any information >about serial output formats.It's out there but IIRC it took some diging to find.> I've got this far: I've configured it for >UDP, and sent a UDP packet with a string of ASCII alphanumeric characters >as payload (using the Python socket module). > >The serial output then >provides > >* a byte 0x02 -- perhaps ASCII STX, perhaps not >* 4 bytes that could be the IP address of the sending host in big-endian >format >* a byte 0x00 >* a byte containing the number of characters in the payload string >* the payload string. > >I haven't seen anything on the web site or the documentation CD that >confirms or denies these assumptions. In the short term, I guess I can >keep on developing with what I think I've got. > >The guy who did the USB variant of our product used an FTDI chip, and >devised a protocol that put an unequivocal frame mark in the serial stream, >and used a system of escapes to guarantee that no data could be mistaken >for a frame mark. I don't see any signs of this in the XPort output I've >got so far.The frame layout you show plus a state machine and a CRC or checksum should be enough to synchronize. You can add suspenders to the belt, if necessary, with an ACK/NAK handshake, or requiring multiple sequential valid packets at startup or after the receipt of a bad packet, or windowing the control signals, or going to an ECC appropriate for the data structure, or ... Depends, somewhat, on whether a bad packet burns the toast or triggers global thermonuclear war.
Reply by ●September 18, 20082008-09-18
Rich Webb wrote:> On Wed, 17 Sep 2008 12:15:01 -0400, Mel <mwilson@the-wire.com> wrote: > >>Has anybody worked with these? > > Only played with one out of curiousity er ahh, I mean that I evaluated > a development unit with an eye towards possible future use. > >> I'm having trouble finding any information >>about serial output formats. > > It's out there but IIRC it took some diging to find.Any recollection whether it added much to what I've found out? It would be interesting to know how XPort handles UDP checksum failures, what happens on RESET, etc. [ ... ]> The frame layout you show plus a state machine and a CRC or checksum > should be enough to synchronize. You can add suspenders to the belt, > if necessary, with an ACK/NAK handshake, or requiring multiple > sequential valid packets at startup or after the receipt of a bad > packet, or windowing the control signals, or going to an ECC > appropriate for the data structure, or ... Depends, somewhat, on > whether a bad packet burns the toast or triggers global thermonuclear > war.It's for pipe organs, so mistakes would be loud and obvious (except when they're playing Messiaen, somebody said at work.) I don't think anybody would die. Looks like we'd be running the serial link at about 900Kbaud with a maximum data rate of about 600Kbaud, so I might be able to sync up on the gaps between packets -- hard to say yet whether those would show up reliably. A tempting alternative is to just move the whole IP variant to a Netburner board (or equivalent -- suggestions welcome.) The MOD5270 is in the same cost ballpark as our current XPort+PIC board. I presume we could get all the UDP metadata to use, not just an interpretation. Thanks, Mel.
Reply by ●September 18, 20082008-09-18
On Wed, 17 Sep 2008 23:07:38 -0400, Mel <mwilson@the-wire.com> wrote:>Rich Webb wrote: > >> On Wed, 17 Sep 2008 12:15:01 -0400, Mel <mwilson@the-wire.com> wrote: >> >>>Has anybody worked with these? >> >> Only played with one out of curiousity er ahh, I mean that I evaluated >> a development unit with an eye towards possible future use. >> >>> I'm having trouble finding any information >>>about serial output formats. >> >> It's out there but IIRC it took some diging to find. > >Any recollection whether it added much to what I've found out? It would be >interesting to know how XPort handles UDP checksum failures, what happens >on RESET, etc.Nothing specific, I'm afraid. I mostly fooled around with the web interface, using information from <http://www.tigoe.net/pcomp/cobox/cobox-web-interface.shtml> <http://ltxfaq.custhelp.com/cgi-bin/ltxfaq.cfg/php/enduser/std_adp.php?p_faqid=943&p_created=1075227796&p_sid=Z9EkKfBi&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPSZwX3NvcnRfYnk9JnBfZ3JpZHNvcnQ9JnBfcm93X2NudD04NjkmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3NlYXJjaF90eXBlPWFuc3dlcnMuc2VhcmNoX25sJnBfcGFnZT00&p_li=&p_topview=1> Some of the regs in the sci.electronics.* groups have used it much more extensively than I. Try posting a query over in s.e.design.>It's for pipe organs, so mistakes would be loud and obvious (except when >they're playing Messiaen, somebody said at work.) I don't think anybody >would die. Looks like we'd be running the serial link at about 900Kbaud >with a maximum data rate of about 600Kbaud, so I might be able to sync up >on the gaps between packets -- hard to say yet whether those would show up >reliably. > >A tempting alternative is to just move the whole IP variant to a Netburner >board (or equivalent -- suggestions welcome.) The MOD5270 is in the same >cost ballpark as our current XPort+PIC board. I presume we could get all >the UDP metadata to use, not just an interpretation.A not-impossible alternative, if you're using UDP, is to write the handlers yourself. TCP, especially a "full stack," involves quite a dance but the hardest thing in UDP is the freaking checksum. "Networking and Internetworking with Microcontrollers" by Fred Eady has a relatively painless step-by-step description of the process.
Reply by ●September 18, 20082008-09-18
Rich Webb wrote:> On Wed, 17 Sep 2008 23:07:38 -0400, Mel <mwilson@the-wire.com> wrote:>>>> I'm having trouble finding any information >>>>about serial output formats. >>> >>> It's out there but IIRC it took some diging to find.[ ... ]> Nothing specific, I'm afraid. I mostly fooled around with the web > interface, using information from > > <http://www.tigoe.net/pcomp/cobox/cobox-web-interface.shtml>These people have got results they like. I'd better go over the configuration option bits very closely before I give up. There's every possibility that good stuff is there. [ ... ]> A not-impossible alternative, if you're using UDP, is to write the > handlers yourself. TCP, especially a "full stack," involves quite a > dance but the hardest thing in UDP is the freaking checksum. > "Networking and Internetworking with Microcontrollers" by Fred Eady > has a relatively painless step-by-step description of the process.Many thanks. I'll chase these leads down, then see what the boss thinks. Mel.
