We're trying to read data from a digital yacht AISnet base station on a linux box. From what I've read, Digital Yacht has drivers for both osx and windows (but not linux for this unit) and their job is to create a virtual com port so that the device can send an NMEA 1083 stream as if it's doing RS-232 serial communication. We are OK with parsing the NMEA data ourselves, but I don't know much about drivers. Wondering if anyone has any experience getting NMEA data from a digital yacht or similar device in to linux? Is the USB to virtual RS-232 something common for other devices or something that would be practical to make ourselves? Any pointers much appreciated.
Answering myself: use the GPSD gps daemon, as GPS uses the same protocol as AIS (something I didn't know when I posted the initial question and was first dipping into AIS). GPSD handles listening to the stream of raw NMEA data on the device and provides a high level interface to get the data already parsed to JSON. It was very easy to get going on linux and supposedly also runs on OSX though I haven't tried it.
If using Python, there is also a client library for working with the GPSD stream to making AIS listening applications.
GPSD: http://www.catb.org/gpsd/
https://github.com/wadda/gps3/blob/master/examples/agegps3.py
Related
I want to test my usb device firmware. I'm looking for a host tool to generate get/set reports to exercise my USB device. Handling INPUT requests and generating OUTPUT requests would be a bonus.
Are there any generic tools to send a USB message? Any python tools to recommend?
It seems like a pretty generic need but I havent found much in my web searches.
Hopefully I will have more luck today. I have no prior USB integration and about 8 months of learning embedded systems on Atmel devices. I am trying to use an Atmel SAM L series to connect over USB to a computer. The use case is for data transfer. Specifically, the MCU will be gathering data from it's sensors and packaging it for USB transfer.
I have searched through and read up on all of Atmel's included USB examples. I have also started reading through usb.org's class specifications for CDC.
I have running now something that lets me send data along one com port, into the target usb and then out the debugger usb to another com port. However, I don't think this is real USB.
My problem is two fold.
1.) I do not fully understand what differentiates USB from serial communication on a com port.
2.) Even if I were doing it correctly, I'm not sure how to test and verify that I have indeed created a legitimate USB device that can be accepted by a host computer.
Links to documentation(Atmel or generic) or example code would be appreciated.
1) USB is defined in the USB specifications from http://www.usb.org. Serial ports were an older and simpler interface that involved sending data back and forth asynchonously on pins with names like TX and RX. The USB CDC class and its ACM subclass allow you to make a USB device that emulates a serial port. If you make your device be a USB CDC ACM device, then you don't need to supply any drivers for Windows 10, Linux, or Mac OS X.
2) You can read the USB specification and the CDC ACM specification. You can run the USB command verifier. You can test your device with a variety of different USB hosts to make sure it works.
I want to use the STM32F4 microcontroller to receive a video stream then stream it over ethernet with the rtsp protocol .
I need you guys to tell me wich circuit would be the best for interfacing with STM32.
Can I interface a webcam with the STM32 via the USB OTG ? (I have basic ideas about usb protocol, but the problem is that the webcam I have is not supported by linux so there is no code source for the drivers, so no Endpoint references ...)
Is it possible to define Endpoints and vendor-specific commands that trigger the bulk transfer of video ( streaming ) by debugging the usb traffic ?
Or, would you recommend another circuit that provide video stream simple to interface with the STM32 .
I know this is kind of crazy thing to do, but I'm asking how hard it's gonna be ?
Let me know what you think of this project ?
PS:
The rtsp part of the project is not the purpose of this topic .
Thanks in advance.
You can't easily run linux on an STM32F4, nor is getting a USB stack running on it, and writing your own webcam driver trivial. I would recommend going with some sort of embedded camera, or moving up to a processor that can support a full linux distro running on it.
As stbtrax mentioned the STM32F4 processor cannot really handle video processing, so your best to move to an embedded OS system such as Odroid.
Another option is to interface a camera direct to STM32F4 using DCMI and then stream theis over USB using UVC as this guy has done. You will be limited with resolution here.
https://github.com/iliasam/STM32F4_UVC_Camera
Just as the question states, the goal is to reverse engineer the protocol used by a device.
Let's say you have a webcam, an Arduino and an Arduino USB Host shield. You want to talk to that webcam, from which you don't know the protocol. Can it be done by monitoring USB data packets and by analyzing the driver installed for that device?
It would be a really interesting project.
Thanks in advance.
I often use a serial spy program to look at the conversation between two devices. In windows you can pay for it...
http://www.sinnovations.com/htdocs/serial-port-monitor.htm
In Linux it's free...
http://www.cyberciti.biz/faq/howto-monitor-data-on-a-serial-port-in-linux/
Is there a place where I can find documentation or an SDK about the Logitech Unifying Receiver?
I recently obtained a wireless mouse, which came with a Logitech Unifying Receiver (a small USB dongle that plugs into the computer and communicates with the mouse/other compatible devices (such as keyboards)).
I wanted to try writing an app for my smartphone that pretends to be a mouse and sends data to the receiver.
I was able to monitor the data from the USB bus by using usbmon, and could probably use that to hack something out, but wanted to know if I could find the info I need somewhere on the internet without having to derive it on my own.
I'm going to try using SL4A on Android, if that helps any.
I have discovered some Logitech documents on a shared folder in Google Docs via this Chromium bug report. For convenience, I converted all doc(x) files to PDFs and put those on https://lekensteyn.nl/files/logitech/.
You will find Logitech HID++ 1.0 Specification for Unifying Receivers (pdf) very interesting, it describes the USB traffic (instead of the 2.4GHz wireless traffic as noted by Avery). My article Logitech Unifying for Linux: Reverse Engineering and unpairing tool documents a way to capture the traffic with usbmon and QEMU. It also includes tools to make the usbmon output prettier to read (for this protocol).
This is Avery, aka Tequals0. The USB dongle is a USB HID mouse/keyboard device, so all that traffic that you are seeing is basically generic HID traffic- if you want to pair your phone to your dongle, you will have to emulate the wireless traffic, not the USB traffic-that is generated by the dongle.
There is some info at Tequals0 blog, and AveryLouie also got some python tool operating with unifying