Emulate the addition of new computers the local network - c++

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.

Related

Custom dashboard for car; Reading OBD II data using C++?

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).

STM32 LWIP PPPos implementation

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.

Triggering a second PC via ehternet

I'm trying to use Psychopy to trigger a second machine's data collection. I could use an I/O card, but I wondered how difficult it would be to use the NICs in Ad-Hoc mode?
Thank you
We are currently communicating with an eye link 2 running our experiment on one machine and the eye link software on another. In some tests of the mirametrix eye tracker we also used some variations of virtual and real machines talking to one another (as an aside, we never quite got the performance from the mirametrix that we needed).
We mention some of the tools we used here: https://brittlab.uwaterloo.ca/research-tips/
If you have a network card in each machine you could just connect them with an ethernet cable and set up tcp/ip to let the programs on the two machines talk to each other. If one machine needs to also talk to the outside world you could add a second network card (or if a laptop just buy a cheap usb wireless).
With more specifics about what you are trying to achieve others may be able to give you more specific feedback.

Register to the DeviceManager of Linux

I read some questions here but couldn't really find the specific problem I'am faced with here...
I need to implement a "DeviceCache" in a particular project which caches all device-names found in /proc/net/dev .
The Language is C/++
So I thought about a seperate thread looking every X seconds in the directory mentioned above but was encouraged to find a more direct way.
How can I register a method of my process to the device manager of linux?
Is there a similar way like events/signals?
I looked in other sites but couldn't find any helpful code... Im relatively new to Linux-programming but willing to learn new things :)
Based on your comments, what you really want is to track which network interfaces are operational at any given time.
The only true way to determine if a network interface is up is to test it - after all, the router on the other end may be down. You could send pings out periodically, for example.
However, if you just want to know if the media goes down (ie, the network cable is unplugged), take a look at these SO questions:
Linux carrier detection notification
Get notified about network interface change on Linux
If you just want to be notified of the actual hardware-level registration of interfaces (eg, when a USB NIC is plugged in), you can use udev events if your platform has udev; otherwise, I believe there's another netlink category for hardware addition/removal events.

Simple USB host stack

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.