Video data compression for serial link

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I have a client who needs to send 10 bit greyscale video data
over a serial link from a PC to an ARM Cortex uP. Right now just using a  
KISS implementation, constant-overhead-byte-stuffing protocol, two bytes  
per value, with a simple CRC-type checksum appended to each scanline the  
link needs to be around 384kbps to support the amount of
data required to transmit.

the hardware is on-paper capable of that but in practice the lash up is  
unstable, there's a bottleneck somewhere, most likely on the PC side as  
it's not a "real" hardware serial port but virtualized via USB and it  
has to go thru all the multiple layers of abstraction from the  
application until it finally gets spit out; the application code isn't  
even complied it's from a scripting language.

Using compiled C/C++ that can do system calls directly will probably  
help but I'm also looking for ways to compress the serial stream  
bandwidth. For 10 bit greyscale data I was thinking that just something  
like u-law or A-law encoding could significantly reduce the bandwidth  
without resorting to more compute-intensive bespoke video compression  
algorithms. Primary requirement is that the link needs to be very  
fault-tolerant and reliable for long term operation

Re: Video data compression for serial link
On Sunday, April 28, 2019 at 12:11:55 PM UTC-7, bitrex wrote:
Quoted text here. Click to load it


FTDI  makes a lot of USB/serial chips, but they ALSO make a USB/parallel
chip with FIFO  , the FT245R.   Look into that, would be my first suggestion

Re: Video data compression for serial link
switch from 2 byte parcels with 10 bits of data to 4 byte parcels with 3  
10 bit data words? be fast as possible with a buffer at the reciever?

Hul

Quoted text here. Click to load it



Re: Video data compression for serial link
On 4/28/19 4:25 PM, Hul Tytus wrote:
Quoted text here. Click to load it

the uP is 32 bit so working with the native word-width packets seems  
like a prudent optimization to start with

Quoted text here. Click to load it


Re: Video data compression for serial link
On 28.4.19 23:31, bitrex wrote:
Quoted text here. Click to load it


I'm running a 1 Mbit/s bit-stuffed serial link between two AT91SAM4
Cortex-M4 processors. The processors are doing other activities besides
running the link, which bridges Ethernet frames.

I suspect that the only interface on the PC guaranteed to be fast
enough is the network connection. The PC software is notoriously
excellent in losing serial link speed.

--  

-TV

Re: Video data compression for serial link
On Sunday, April 28, 2019 at 3:11:55 PM UTC-4, bitrex wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

What does "unstable" mean?  Do you loose data or are there simply variable  
delays?  Do you buffer up data in the CPU for display?  I would think you'd
 want to understand the problem before you try to find a cure.  

I don't think the eye has the same sensitivity to light as the ear does to  
sound.  uLaw works by approximating a log relationship which matches human  
sensitivity to sound.  More resolution is given to soft sounds extending th
e effective number of bits than what is transmitted.  

If you are convinced the problem is too high bandwidth, I agree with Hul, y
ou are adding 6 bits of overhead by having empty bits on each word.  With H
ul's packing you can shove the CRC and a sync bit into a 32 bit word and ge
t a 60% bandwidth increase.  If you need to, do the data reshuffling and CR
C check in a small FPGA and present the CPU a FIFO interface via SPI like s
ignals where the overhead isn't important.  

--  

  Rick C.

  - Get a 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Video data compression for serial link
On 4/29/19 7:10 AM, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

The KISS communication implementation works perfectly fine for a while  
and then both the uP and PC app lock and it fails utterly. transmission  
stops. annoying problem to diagnose. Logging the data on the link  
doesn't show anything unusual just prior to it happening.

About all I can say at this point is that it doesn't happen (at least  
not over the course of a day's runtime) at lower data rates. And that  
since the transmission is only one-way I don't see any good reason for  
the PC application to lock up other than the issue originating on that  
side of things.

Quoted text here. Click to load it

all human senses are more-or-less logarithmic in response. the  
difference in actual brightness between walking outside into a bright  
spring morning like today, from say an office lit in a usual office-way  
with ceiling fluorescents is like, a million times brighter outside  
(sorry not really an optics-guy I don't know the appropriate unit to  
use, here.) but we don't go blind

Quoted text here. Click to load it

In any case it was just an idea on how two bytes of data could be  
stuffed into one, in fact since the data is only 10 bits I'd first just  
try right shifting 2 on the way out then left shifting on reception.

It may be that the re-write of the transmission code in C solves the  
immediate problem so some of my request is just for my reference if  
further optimization should be necessary. Byte-packing, at the very  
least, doesn't seem like premature optimization regardless.

I've been doing a CRC for each line rather than each frame as the client  
doesn't need pixel-by-pixel correctness, if a line is wrong then just  
dump it and wait for the next frame.

Re: Video data compression for serial link
On Mon, 29 Apr 2019 13:04:32 -0400, bitrex wrote:

Quoted text here. Click to load it
Do you have timeout settings?  Sounds like at high data rates part of
the packet is getting lost on the PC and the PC is waiting for the rest
of the packet and the uC is waiting for a ACK/NAK to continue sending the
next frame.

[ snip ]


--  
Chisolm
Republic of Texas


Re: Video data compression for serial link

Quoted text here. Click to load it

What USB-to-serial adapter/dongle are you using?

I had somewhat-similar problems when trying to run a Bitscope from a
PC... it would work for a while and then the communication would
freeze up.

The problem appeared to be the USB adapter I was using.  It was one of
the inexpensive "translucent blue" adapters, that claim to have a
Prologix PL-2303 serial-to-USB bridge inside... but very probably had
a clone/counterfeit chip instead.  I've heard other reports of these
counterfeit chips locking up under heavy load... timing or
chip-firmware problem, I suspect.

I swapped the adapter for a known-good FTDI serial adapter (Mouser and
Digi-Key are both authorized FTDI distributors, so you can be pretty
confident that they aren't selling counterfeits) and the problem went
away.

As to compression:  A simple logarithmic-encoding scheme (akin to
A-law or u-law), followed by a run-length-encoding, might do what you
want, without introducing too many artifacts (although there will be
some).  Another approach would be a 16-to-8-bit quantization with
Floyd-Steinberg error diffusion... this will give you a fixed 2:1
compression with (I think) fairly decent visual quality, and it would
be quite fast to implement.


Re: Video data compression for serial link
snipped-for-privacy@coop.radagast.org (Dave Platt) wrote in

Quoted text here. Click to load it

USB is a serial interface.  Doesn't putty interface directly to a  
usb port without a serial adapter?

  Seems that one could write an easy app to do the whole thing.
Putty source code migt be a good read.

Re: Video data compression for serial link
snipped-for-privacy@decadence.org wrote in news:qa7hca$1brk$1
@gioia.aioe.org:

Quoted text here. Click to load it

  It appears that what one needs is a RTMP (Real Time Messaging  
Protocol).


Re: Video data compression for serial link
On 29.4.19 21:56, snipped-for-privacy@decadence.org wrote:
Quoted text here. Click to load it

USB is used to get into the PC. The link from the USB dongle
to the Cortex is asynchronous serial (often miscalled RS-232).

--  

-TV


Re: Video data compression for serial link
$k4s$1@dont-email.me:

Quoted text here. Click to load it
a
utterly.
data
from
would
to
load...
(Mouser
Quoted text here. Click to load it
be
to
what

  No, it is just that RS-232D is the most commonly used asynchronous  
serial communications schema at the physical layer.

  EIA RS-232 is the most commonly used and the most common start-
stop signalling is ASCII.  

Re: Video data compression for serial link
On 30.4.19 03:53, snipped-for-privacy@decadence.org wrote:
Quoted text here. Click to load it


You're a bit mislead: EIA RS-232 is an electrical specification for
connection of a data terminal equipment (computer/terminal) and a
data communication equipment (modem etc), originally for asynchronous
transfers up to 20000 bits/s, using voltage level signals.

The character transmission in start-stop mode is a different story,
as is further the character coding (usually a variant of the ISO 646
standard, like ISO 10646).

It is a common mistake to include the asynchronous octet transfer
and character coding into 'RS-232'.

--  

-TV

Re: Video data compression for serial link

Quoted text here. Click to load it

 I am not misled.

Quoted text here. Click to load it

  Yeah...  Physical layer.  Just like I said.  Not misled.


Quoted text here. Click to load it
  Sure.

Re: Video data compression for serial link
On Tuesday, April 30, 2019 at 3:25:02 AM UTC-4, Tauno Voipio wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Video data compression for serial link

Quoted text here. Click to load it

Yes, that's probably true.

In many cases, it works, and the hardware survives.

In other cases, e.g. where somebody connects a real RS-232 port
directly to a micro serial port that uses 3.3-volt CMOS voltage levels
and non-inverted polarity, it doesn't work (for several reasons) and
there's often a quiet PHUT and a small leakage of magic blue smoke.

As Durano said to Londo Mollari, "The details are everything."

Re: Video data compression for serial link
On Tue, 30 Apr 2019 10:24:57 +0300, Tauno Voipio

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: Video data compression for serial link
Quoted text here. Click to load it

No, in general it does not.

USB is a serial bus.  It's not either electrically- or
protocol-compatible with a "serial port" in the sense that most people
have used the term historically (an asynchonous serial port, using
either RS-232 voltage levels or a TTL-voltage sort-of-approximation of
same).  Instead, a device plugged into a USB bus adopts a device
address, and then presents the host with a flexible set of "USB
endpoints" which can receive, and send, various sorts of packetized
data.  

"putty" and similar terminal emulators assume the existence of a
kernel device interface which "looks like" a PC serial port interface
at the software level... that is, it supports arbitrary-length reads
and writes, it has a concept of "baud rate", it implements (or
pretends to implement) normal RS-232 handshaking, and so forth.  A
"real" serial port will present such an interface as (e.g.)
/dev/ttyS0.  The Linux console emulates such a device as (e.g.)
/dev/tty0, /dev/tty1, and so forth.

If you try to tell putty to (e.g.) "open up and talk to whatever is
plugged into USB port 2 on the front of my machine" it will have no
idea what you're talking about.  It can't talk to USB ports per se,
nor to arbitrary USB devices.  It can only talk to thinks that "look
like" RS-232 serial ports at the programming level.

USB serial adapters have one or more data endpoints, that can be
recognized by their device drivers.  The device driver then presents a
programming interface such as (e.g.) /dev/ttyUSB0.  The driver
translates between the kernel's normal "serial port" programming API,
and the necessary packet-oriented communication with the USB serial
adapter (and this packetized communication is usually manufacturer-
specific and often device-specific).

These days, when you hook a PC to a microcontrollers via a "serial"
connection, it's common to use such a USB serial adapter (and the
necessary driver on the PC side).  On the microcontrollers side, the
communication is often "TTL serial", using TTL or CMOS voltage levels,
and inverted in polarity from what RS-232 requires.  Most
microprocessors which have "serial port" pins, expect this sort of
signaling.  Some have the necessary USB-to-serial chip on the micro
board (it's often called a "USB bridge" in this case), and these
micros can be cabled directly to a USB port on a computer.  The
USB-to-serial adapter is still present (you just don't see it as a
separate piece of hardware) and you still need a serial-port-
emulation driver on the PC.

There are a few microcontrollers which provide their own "native USB"
communication interface and endpoint... usually using a newer standard
called ACM ("asynchronous communication module" I believe... could be
wrong).  Linux will show these as (e.g.) /dev/ttyACM0, /dev/ttyACM1,
and so forth.  You can think of these as "built-in USB-to-serial-like
protocol, which provides buffered bidirectional communication at USB
speeds, doesn't have the concept of 'baud rate', and doesn't pretend
to implement RS-232 hardware handshaking or flow control pins."  You
still need a driver on the PC side for such devices, but Linux (for
one) provides a standard driver which should work with any such
device.

putty and similar programs will work with ACMs just as they work with
RS-232 serial ports, Linux consoles, and vendor-proprietary
USB-to-serial adapters.

There are also "USB gadgets", which is a whole different level of
complexity.  The BeagleBone Black board takes on the role of a
network-interface-like gadget when you plug it into a PC - the kernel
sees what appears to be an Ethernet-like interface and can run normal
networking protocols over the cable.




Re: Video data compression for serial link
On 4/29/19 3:58 PM, Dave Platt wrote:
Quoted text here. Click to load it

Yes, the device we're using is ACM. on linux the uP's port is accessed  
thru /dev/ttyACM0. On a Mac its identifier is some bizarre gibberish but  
works the same.

On the API side of things however there does seem to be a concept of  
'baud rate' as one still has to define a link speed in software prior to  
transmitting or receiving data.

Site Timeline