Video data compression for serial link

Thank you Martin, you have good suggestions here that will take me some time to explore but I'll update when I have more answers.

The good news is this design will be talking to Macs or Linux machines only - no Windows here.

While Windows is not a hard RTOS, this affects mainly half duplex causing large latencies, if some protocol is done in user mode. Assuming a half duplex slave protocol, the kernel mode driver receives the request and tries to wake up the user mode protocol processing. The user mode activates after some undefined amount of time, generates a response, which is sent by the kernel mode driver back to the serial line. The foreign master sees this as a greatly varying response time and if the master timeout is set too tightly, may eve timeout, before the response from Windows arrives.

Last century, some bad PC hardware caused a lot of lost interrupts on serial lines by disabling interrupts. Some floppy and CD controllers, some Ethernet adapters and some display adapters were particularity bad. By avoiding these bad apples, the Windows serial handler can capture all received bytes, before any UART hardware with reasonable sized hardware FIFO overflows.

I haven't seen such problems with modern hardware.

The next problematic point is the kernel mode to user mode transition. By using SetupComm() quite large kernel mode buffers can be allocated, into which the kernel driver inserts more bytes, until the user mode code wakes up and handles the received bytes. If the user mode protocol code doesn't call SetupComm(), at least previously, the default kernel mode Rx buffer was quite small, increasing the risk of overflowing the kernel mode buffer.

snipped-for-privacy@downunder.com wrote in news: snipped-for-privacy@4ax.com:

RTMP Real Time Messaging Protocol. It buffers things and reduces dropped frames. Made for streaming.

So, a different networking protocol?

As long as USB is universally available, though, a hardware solution (first-in-first-out memory buffer) is as easy to add as replacing the USB/serial dongle with a USB connection through a FT245 interface chip.

Involving a full network of switches and wires, just doesn't seem useful when a short-distance one-computer-one-peripheral link is wanted. There's too many points-of-failure.

I sent back and re-checked this, and you're right - that sort of negotiation is supported, although not mandatory.

The endpoint is what's known as a CDC (Communications Device Class). This class has commands defined which allow the host to query, and set, the line coding (bits per character, stop bits, baud rate) and the hardware handshaking. In effect, you _can_ do to a full-featured CDC, what you can do to a normal host-attached serial port.

I recall now that I have a small USB-attached faxmodem at home which works this way.

You could, if you wish, actually implement an RS-232 serial port via such a CDC endpoint, with full hardware handshaking. In effect, this class is capable of being a standards-conforming equivalent to the sorts of proprietary USB implementations that FTDI and Prologix and etc. do in their serial-to-USB converters.

It's also possible to implement a CDC which does not implement these line-related commands at all - they're optional. You'd do this if you want a CDC which behaves very much like a speed-independent, hardware-independent serial port... that is, you can send a string of bytes to it, read bytes back, operate in full or half duplex, etc., but without having to worry about the concept of baud rate.

You might, for example, implement a speed-less CDC inside a microcontroller, creating a "console" or "terminal" interface. This would be more efficient and reliable, in some ways, than using the micro's own RX and TX serial port pins, because the traffic between host and micro would be carried directly in USB "URBs" as sequences of bytes with full flow control. There would never be a need to do RS-232-serial-like conversion between bytes, and individual bits flowing over a single serial line. You could read or write hundreds of bytes per operation, rather than having to take individual interrupts every character or every few characters.

This looks like an example of what you're talking about:

Seems promising; strict serial is more appropriate for intermittent async communication what I really need is higher bandwidth continuous transmission

but then the MCU has to handle USB instead of just DMAing bytes to a UART

so it isn't necessarily any better

you want a look up table like this. It might not solve all your problems but at least it will halve the required bit rate which should improve things. Note the darkness details (up to 63) are not compressed at all.

{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,

16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 65, 67, 69, 71, 73, 75, 78, 80, 82, 84, 87, 89, 91, 94, 96, 99, 101, 104, 106, 109, 112, 114, 117, 120, 122, 125, 128, 131, 134, 137, 140, 143, 146, 149, 152, 155, 158, 161, 164, 167, 171, 174, 177, 181, 184, 187, 191, 194, 198, 201, 205, 208, 212, 216, 219, 223, 227, 231, 234, 238, 242, 246, 250, 254, 258, 262, 266, 270, 274, 278, 283, 287, 291, 295, 300, 304, 308, 313, 317, 322, 326, 331, 335, 340, 345, 349, 354, 359, 363, 368, 373, 378, 383, 388, 393, 398, 403, 408, 413, 418, 423, 428, 433, 438, 444, 449, 454, 460, 465, 470, 476, 481, 487, 492, 498, 503, 509, 515, 520, 526, 532, 538, 543, 549, 555, 561, 567, 573, 579, 585, 591, 597, 603, 609, 616, 622, 628, 634, 641, 647, 653, 660, 666, 673, 679, 686, 692, 699, 706, 712, 719, 726, 732, 739, 746, 753, 760, 767, 774, 781, 788, 795, 802, 809, 816, 823, 830, 837, 845, 852, 859, 867, 874, 881, 889, 896, 904, 911, 919, 926, 934, 942, 949, 957, 965, 973, 980, 988, 996, 1004, 1012, 1020}

Cross over network cables are available for point to point connections. I still have one somewhere - it is purple to avoid confusion.

--
Regards, 
Martin Brown

Ah, the "good ol' days" I remember owning some of those. Not since either 100 mbit or Gigabit Ethernet became common on just about everything, whatever the standard was where the port hardware itself was able to auto-negotiate that stuff.

In college I worked for the IT department helping setting up other student's networking, in 1997 it was still common for students to be bringing machines from home from the mid-late 80s like the Macintosh SE and wanting them on the campus network. It was possible using aftermarket equipment like Ethernet to Appletalk bridges, but it was pain.

Hi David, sorry for the delay in my reply - if you're around can you tell me how you came up with that table? And/or how to adapt to a different bit depth?

A formula that will work to give the same transform approximately is:

x = int( 0.5 + 0.998*y*(4096+y)/(4096+16*y))

maps 0

Only to the pedantic. While what you say is correct, it's not important. Virtually everyone refers to an async serial port as RS-232 even when the v oltage levels are something different. Like calling photocopiers "Xerox" m achines or using saying they'd like a "coke" when they mean soft drink.

Even more common is to just shorten it to a "two-thirty-two" port.

--

  Rick C. 

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

I'm testing it out this week. The requirement was the final deliverable be written in C++ anyway so that was the priority and almost finished, now.

The client's own scripting-language template for what they want was kinda kludge-y it's been re-written in a modular way such that it's easy to "plug-in" various encodings and compression schemes to test

That is to say the scripting language implementation behaved erratically in general, not stable enough to tell anything for sure. It's not really appropriate tool for the task and the data rates involved

The RS-232 was also used for _synchronous_ to connect DTE to DCE. Look at the RS-232 signal list, there is also the Tx-clock from DTE and Rx-clock from DCE. Later on, when the D-connector was standardized for RS-232 this too included the Tx and Rx clocks and secondary channel etc. These are not required for asynchronous connection.

There are a whole family of such curves of the form

x = int( 0.5+k*y*(A+By)/(A+Cy))

for 0 kinda kludge-y it's been re-written in a modular way such that it's easy

The simplest one would be to drop the most significant byte. TBH I'm surprised a scripting language can keep up with a video stream at all.

--
Regards, 
Martin Brown

It was some Java code, so not exactly the proper terminology it was not interpreted but compiled for the Java virtual machine. I was a little surprised that Java could access a USB serial interface as well and it does okay but the transmission must have to propagate down thru many layers of abstraction to the actual hardware.

It's probably fine for logging stuff at a few dozen kbps intermittently but trying to send a continual stream of dummy data at a hundred kbps will intermittently hang the app, even on a very recent high performance laptop. It's not the interface's problem it can push that amount of async data no problem when C code on Linux is driving it directly from a /dev handle to it.

in 2019 the way we roll (as opposed to what they did in their mockup) is that the application logic is abstracted away from the hardware interface logic, which is abstracted away from the datastream logic. The interface is something. it doesn't matter what it is. it accepts a stream of bytes.

The application logic generates its data. and the datastream logic has a compression policy, an ecc policy, an encoding policy that massages the application output into a stream of bytes the interface logic accepts. And the reverse on the other side.

Dropping the MSB is called e.g. DumbCompression and that's a template that plugs-in at compile time, there's no run-time cost associated with that fashion of polymorphism.