So I am in a bit of a dilemma, I want to create a LED dashboard using my Raspberry Pi, the only problem is how am I going to read the data to the Raspberry Pi using C++? I am thinking about buying an OBD to USB connector and reading the data from there, but it still doesn't change the fact that I would need parse the data, but the only library I found for OBD on C++ is https://github.com/lkrasner/obd-cxx but it does not look promising.
So this is where I turn to the Stack Overflow community to help me out because I have run out of options.
Can the OBD data be read as serial? If it was serial, wouldn't that be too slow for a real-time speedometer? Should I use another port instead of OBD?
I have quickly searched and found this topic: http://blog.lemberg.co.uk/how-guide-obdii-reader-app-development
It is not usb, but it tels about AT commands to communicate with the adaptor. Thus, I would assume the USB one will be visible as a serial interface with the same communication principle. Then you might not need a library, as you can directly read-write your serial device.
Make sure only, that the adaptor you're gonna buy supports the communication protocol of your car (CAN or another). Perhaps also one option to think about is whether the adaptor provides high-level commands for you (then you need to check that the required diagnostics services are supported by the adaptor), or you need to build/parse the raw diagnostic messages yourself (I think this would be more flexible solution).
Related
On my STM32F7 I have to connect a 3G modem using serial port.
I can communicate with the modem using AT commands.
I would like to use PPPos (PPP over serial) library from LWIP to enter in PPP mode. So I take a long look at the official documentation
http://lwip.wikia.com/wiki/PPP
and
https://github.com/tabascoeye/lwip/blob/master/doc/ppp.txt
I understand the guideline but I'm really surprise there is no implementation example with serial port. Indeed, I think there is a lot of modems that have a serial interface, so I thought i can easily find an example of use.
Anyone have already done that or has an example ?
While I cannot publish my example, the general idea when it comes to integrating TCP/IP stack of your choice with its PPP driver is the same among all serial modems and all TCP/IP stacks that I've worked with.
Generally as you've mentioned, you start with configuring the modem using AT commands - things like checking whether SIM card is present, whether it requires PIN, specifying PIN if needed, checking if it has successfully registered in the network. Possibly reading additional information data such as IMEI, IMSI as well as diagnostic data: signal quality, BER etc. Once you're done, you switch the modem to "data" mode (see ATD*99), wait for the modem to respond to that command and pass the responsibility to the TCP/IP stack, as at this point the modem starts talking PPP.
When it comes to integrating your modem with the stack so it can communicate with it, the implementations I've encountered all require implementing some form of low-level API functions for the stack. For LwIP, the wiki page you've linked in the "PPP over serial" section, it is described quite well how those functions should behave. Because TCP/IP stacks are just a software library not tied to specific hardware and they can be run on almost anything (assuming sufficient resources), specific API implementations such as the one discussed are not always provided - there would have to be a ton of examples for it to provide any value. Although if you google around for it, you might find someone having done it for the MCU that you use personally. Assuming you've already done the part where you successfully comminicate with your modem using AT commands, it shouldn't be much more other than using the send/receive functions you already have. Some slight changes may be required, such as adjusting their behavior (synchronous->asynchronous or vice versa) or redirecting received data to the TCP/IP API receive function instead of your AT command parser. Nonetheless, most of the necessary hard work should be done already.
Once the TCP/IP stack takes over, you continue with the modem using provided stack PPP API. For LwIP see functions such as: pppSetAuth, pppOverSerialOpen. Those will cause the stack to internally handle the necessary communication with the modem over PPP: LCP, PAP/CHAP, IPCP. Once that part is done (you retrieve IP configuration data from the network) it becomes transparent how this operates - it becomes one (of possibly multiple) network interfaces and you use it just as any other one, for example using socket API.
I am posting here concerning the emulation of computers on the local network, without destroying the local network.
When a computer connects to wifi on your local network, the computer can be seen in the "Network" section of Explorer(on Windows) and can be addressed via internet protocol.
My Goal: I would like to create a program such that I could receive streams of data from a remote computer via radio waves. The communication would be full duplex, there would be a transmitter and a receiver on both ends.
My Idea: I would like to utilize Qt to create an application which would receive and demodulate the radio waves like sound (through OpenAL buffers) which would act similarly to a driver program for the emulated computer connection, without destroying my connection to the local network. In this way, I believe that some truly novel things could be done, as I could for instance, use PuTTY one the emulated connected computer remotely while browsing my local network and the internet from my "base" computer.
Extended explanation: I want to perform a weather balloon project, sending a small computer (likely Raspberry Pi3) via a weather balloon to the far reaches of our atmosphere. One of my worries is being able to communicate with the device, such as receiving locational (telemetry) data in real time and being able to (potentially) retrieve arbitrary data in real time.
I understand that I may very well be approaching this question in the wrong way. There are probably existing systems out there that grant telemetry data and some arbitrary means to transfer file data, of which I am unaware. But from what I have seen, I also cannot find a device that utilizes this approach (packet radio emulation of a computer on the network). I have a personal curiosity towards this approach, and thusly will accept the answer which follows most in line with this approach.
P.S: Video which inspired this idea:
https://www.youtube.com/watch?v=Ueb5JG0dCL8
What you're trying to do is called software-defined radio, and is rather popular. Modern computers, even little ones, are more than powerful enough to do the modulation/demodulation entirely in software.
There's very little left for you to do other than designing the RF channel, purchasing often open-source hardware, and using existing open-source SDR implementations out there. The input/output to your Qt program would be either a QIODevice-like data stream that you'd couple to the SDR library's data scrambler/descrambler, or a packetized data stream that you could run some higher-level protocol on.
Do note that unless you limit yourself to an industrial license-free band, you are likely to need an FCC license to operate the transmitter, and an FAA license to launch the balloon.
Your question is essentially off-topic here. It probably belongs on amateur radio stack exchange under the [sdr] tag.
If you're thinking of implementing a complete WiFi stack using SDR, I'd like to discourage you: it's patent-encumbered up the wazoo, so no open-source implementations exist, and the sheer amount of standardese you'd have to wade through to do a compliant implementation is staggering. We're talking on the order of 5,000 pages of standardese, where almost every other sentence is important so if you ignore it, you're not compliant.
I am developing C++/Qt application which interacts with Tektronix TDS2002 oscilloscope via USB. The oscilloscope appears as "USB Test and Measurement device (IVI)".
Currently I use TekVISA library supplied by the oscilloscope's vendor. It works, but it is huge, old, buggy and poorly maintained. Therefore I would like to bypass the library and interface the device directly.
So far I have found this simple library: https://github.com/xyphro/WinUsbTmc It is exactly what I am looking for, but it uses libusb which requires to install some device filter and in addition it is advised to be more development tool than customer solution. Do you have any experience on this?
What is the easiest way to interact with USB Test and Measurement device in Windows/C++/Qt?
Thank you for your suggestions :)
You need a USB driver. My oscilloscope works with the driver included in this VISA package (the driver can be extracted very easily): http://www.keysight.com/main/software.jspx?cc=CZ&lc=eng&nid=-11143.0.00&id=2504667&pageMode=CV I assume all USB TMC devices can use the same driver, but I have no possibility to check this.
USB driver can be accessed via standard Windows functions. Guys on this forum were really close:
https://forum.tek.com/viewtopic.php?f=568&t=137573 and also this document was very useful: http://www.ivifoundation.org/downloads/Class%20Specifications/Ivi-6%202_USBTMC_2010-03-23.doc
You cannot write commands to OSC directly - data you send and receive have certain header which has to be in the correct format, otherwise the oscilloscope ignores the message. See reading and writting implementation in this simple library: https://github.com/xyphro/WinUsbTmc I didn't use this library because it uses libusb library which uses some kind of device filter and I personally do not like this concept (and in addition I have genuine working driver).
Data you read have also a simple header. To ensure you fit the header structure on input data well, you should first flush the input buffer. Then you issue reading request (using write command - see WinUsbTmc library above) and finally you receive the data and fit the header on its beginning.
I hope this will help to somebody :)
With regards
klasyc
I am working with a pressure-sensing mattress having a USB interface. The maker provides USB device drivers for Windows, and an API written in C++ which has functions to request data and set some parameters.
Currently, I cannot use this sensor for testing some Python data-visualization scripts directly, having had to ask my coworkers to write a text-logger for me, and then I read this information offline with Python.
Also, I cannot use Linux at all with the sensor, because there are not drivers for Linux, and I do not know where to start to "hack" the sensor, and that is why I am asking:
"If I were to try to read data from this sensor directly with Python and perhaps in Linux, what should I do first, or read first?"
EDIT: the device has an FTDI driver (FTD2XX.dll) if it helps.
Any help would be very welcome
Odds are fairly good it's a HID device, in which case you can probably start to write a userspace linux driver for it using libhid. First place to start with that would be enumerating the tree that gives you information about its capabilities. (lsusb -vvv or Example)
Failing that you can use libusb on linux (and other platforms too these days) to write a userspace driver still. You'll want to use something like usbsnoop or a real hardware equivalent to see what the official driver does when it's talking to the device and mimic it from there.
From the python side you can probably generate a decent wrapper to the existing C++ API using SWIG for relatively little effort, especially compared to developing an entirely custom driver.
Update:
If it's an FTDI device then it's might be a lot simpler to work with. Depending on what the vendor and product ID are showing it might automatically work with the FTDI driver in Linux, giving you as USB serial port. Failing that there are parameters to the module - vendor and product that I believe you can use to make it claim other devices besides the pid/vid combinations it knows about already. From there you can try opening the serial port device with different settings. With luck it might be sending state info regularly already.
If it's not you want to try and discover what the official software sends to make it start playing. You're back into the realm of sniffing again, but I think there might well be things that do it at the serial layer instead of the USB layer for windows (although I can't name any). You might also learn something by trying to make their library use a software emulated serial port instead of the FTDI device and seeing what it writes.
The FTDI chips have a linux driver. Just go to the FTDI website and download it. The driver creates a virtual serial port. You can use PySerial to interface with it.
Too bad I didn't see the post sooner!
I am trying to connect to a single USB device using the USB host port on an Atmel processor. I have an embedded system with limited memory and no OS. I want to implement a simple dedicated host to interface to a single USB slave device.
Can anyone guide me to a simple USB host implementation?
The processor is the Atmel AT91SAM9261S.
First of all if i remember correctly AT91SAM9261S have OHCI usb controller on board and you need to implement at least simple host controller driver (you can take a look on Linux implementation) . Depending on the transfer types your device will be using it might be not very hard - to very hard :) There is no trivial way to implement usb stack.
After implementing a controller driver you will need to take care usb device enumeration part take a look at Chapter 9 of USB spec. And only after this you can start implementing your device logic.
For simplified use case there is a lot of code that could be omitted, but without good usb background is hard to decide what is relevant and what is not.
Any way if you are looking for commercial solution my company can provide one.
I've used the RTUSB-32 stack from On-Time. It is a small foot print stack and was easy to integrate into our environment and the documentation is good. They abstract out nicely the needed support so that it is completely platform and OS neutral and has a relatively small number of hooks you need to provide to it - ie: It is well encapsulated.
Since you get all the source, you'll see that the code is not the most well constructed code in the world, certainly, but it can be deciphered without a whole lot of work if needed. In any case, it basically "just works" without issue. We have had it running in some products for a few years now and have only run into one compatibility problem with the stack where it wasn't quite doing auto-discovery quite right with a certain type of USB 2.0 hub. We sent them a sample of the hub and they had a patch for it within a few days. Hard to beat that. Overall, I consider it a good value and certainly beats sitting down to write the thing from scratch.
This would be so much easier if your device didn't have to be a host :-P, because Atmel provides example source code for USB devices. If I were you, I'd look into using one of the USB-loving RTOSs on Atmel's AT91SAM third party page which might entail the USB stack from jungo as suggested by Ilya.
If you do write your own OHCI driver, libusb could be helpful as an implementation of the upper layers of the USB stack.