The OmniPreSense radar firmware’s USB connection is provided via a vendor-delivered library implementing a CDC Device interface on the microcontroller.
The radar firmware does not customize the driver’s operation. An overview of the vendor’s driver can be found here
The host side of the USB connection (not the OmniPreSense sensor) is the primary driver of the connection. The connection will appear as a USB CDC device and no driver installation is typically needed (though the vendor supplies a Windows 7 driver here and OmniPreSense makes it available here )
Be aware that the performance class of the host will affect USB reliability. If one is using a reduced-class processor (such as an ARM processor on a Raspberry Pi or a Celeron) and if that processor is also attempting heavy-duty computation or I/O, then the USB line’s reliability can be affected.
Be aware that the host’s programming environment of choice can also have an adverse affect. Even on a high end PC, the author of this article has seen the PySerial library appear to disconnect and not reconnect, whereas the same sensor connection will stay alive and healthy when using a terminal program written in C. Note that the node.js serial interface on a Raspberry Pi (as used in Node Red) has shown months of continuous uptime.
USB CDC will automatically negotiate the maximum allowable baud rate for data transfer between sensor and host. This can be as great as 12 MBps according to the specifications. This is subject to cable length, cable quality, and throughput abailable at both ends of the connectino.
It is possible to set a baud rate on the connection, but this will merely lower the throughput. (Some devices use the baud rate as a form of security. They will not accept commands unless they are sent at a secret baud rate.) We support setting the baud rate to any of 9600, 19200, 57600, 115200, or 230400 bps. However, setting the baud rate is more of a requirement when using the UART connection.
The OmniPreSense Radar Sensor draws power from the USB port. For best results, the host that the sendor is connected to must have enough power for it’s own operation plus the RADAR sensor. Raspberry Pis expect 2.4A of power, and providing less than 2.4A may cause a pi to provide insufficient power to the RADAR sensor. Please ensure 2.4A is given to a Raspberry Pi
We have found that linux tends to treat our RADAR sensor as if it was a terminal, and echos back the characters that are sent by the sensor back to the sensor. This is a bad behavior and can be very destructive.
When logged into a linux system with a connected RADAR, the command
/bin/stty -F /dev/ttyACM0 -echo
will disable line echo. However, if this is done after the board’s output has been reflected back to the board, it may be “too late” to avoid some failure cases.
Linux systems have a complex and arcane system for managing plug-and-play devices. Udev (think “user devices”) is the system by which devices can be named, and optionally, very fast commands can be run when the device connects.
Below is our current best advice for turning off the destructive echo behavior.
\etc\udev\rules.d\99-com.rulesAdd the line
SUBSYSTEM=="tty", ATTRS{idVendor}=="058b", ATTRS{idProduct}=="0058", SYMLINK+="RADAR%E{ID_USB_INTERFACE_NUM}", RUN+="/bin/stty -F /dev/RADAR%E{ID_USB_INTERFACE_NUM} -echo"
which should manage to stop the undesired echo behavior. To activate this change, either reboot the system, or run the command
sudo udevadm control --reload-rules
Thereafter, as soon as the sensor is connected (more technically, immediately after being enumerated as a USB device),
this will name a radar as /dev/RADAR00 (/dev/RADAR01, and so on), and invoke the command /bin/stty -F /dev/RADAR00 -echo
(You might consider using the device name /dev/RADAR00 and not /dev/ttyACM0 thereafter, but this bit of advice seems to be optional.)