Hello, I have been working on a Python library for doing RC control on the PI-Top. The driving idea behind it has been to create a RC library that uses regular wifi hardware without the downsides of a more standard Hotspot + TCP connection approach. This is accomplished by interacting with WIFI hardware at a lower level, allowing the Wifi hardware to be used as just a radio with the ability to transmit bytes and receive bytes. Anyway, additional info can be found on the github at: https://github.com/aldenq/Yodel/tree/testing and if you want to download it I would recommend taking from the “main” branch or using pip. Also, as of now it only works between linux systems. Thanks for taking the time, any feedback, ideas, etc would be much appreciated.
also, here is a demo video of it being used to control leds on a pi-top from the keyboard of another computer:https://drive.google.com/file/d/1lj4CwTcSQRyvWWX-I9kE1VcnJt7akYiA/view?usp=sharing
@AldenQ this is awesome, I love that you’re using the WiFi hardware for radio - that’s some black magic!
Do you have any measure of the range yet? Also what frequency radio is it?
Thanks, i was able to successfully test out to about 120m with semi-line of sight (a wall and part of a building in the way). Also, individual pi-tops can relay a messages although this was not taken advantage for the aforementioned test. The frequency range that is accessible is the 2.4ghz band, 5ghz could be used but would be almost entirely useless for this application.
Udp is the only other way I can think of to get this snappy of a response. But if you’re doing low level communications, depending on error checking, you can easily extend your range to the 120m or even beyond that. Most rc planes nowadays use low level, low power 2.4GHz communication in the same bands as normal wifi routers.
that could be interesting, i imagine that some of that comes from higher end hardware but i have to imagine that would also apply to higher end wifi hardware. i’ll look into it.
Very interesting, doing thinks like this, do still get 2 way communication to relay info back from thinks like sensors etc? Or have you purely done it 1 way for control.
I only ask as I am starting a project with an RC but not to control as it will be autonomous but looking on ways for communication between 2 devices
should work fine, i have had no issues with pulling data from sensors and sending it over. i would only really expect problems if the discrete chunks of data you were sending over were greater than about a kilobyte.
For me it would be just sensor data and ways around sending more than a kilobyte would be to buffer the data and send it in chunks anyways, don’t think I would even send that much as most the high volume data that I would be logging would be on board and transfer after a run anyways, was more for live telemetry data such as speed, temps, gps, gyro, etc.
Will def look into it for my project 
thanks for sharing your work
sure thing, let me know if you have any other questions.
I may have some in the future. But right now I am just in the starting/concept stage
Yeah. Legally, in the united states, to transmit on any open frequency available to the public and without a license, the maximum transmit power is 500mW. Theres even tighter regulations with 2.4GHz but I dont know them off the top of my head. I want to say it’s like 50 mW or 120? Edit: 63mw and 100mW, depending on what it’s currently doing. Haha
But with 2.4GHz. You dont get the same leeway as you would on a public channel, since it’s not “considered” open to the public.
ya, i coded in some limits on broadcast power but put those in mostly to try and protect people’s hardware. I am mostly just assuming that anyone who tries to significantly exceed the designed power output of their hardware will just destroy it.
That makes me curious, what hardware is being used for the wifi interface? Are you creating custom firmware? Shouldnt the firmware have hard stops against damaging transmission powers?
off the shelf WIFI hardware, from what i can tell the limits appear to mostly be enforced by the OS to comply with the FCC. I can imagine there are also limits in other places but i have not tested it because i don’t really want to destroy my hardware if those limits don’t exist. the code that i am writing sorta takes over some of the responsibilities of the OS and some other systems.
It would be interesting to find out what hardware was used. @duwudi is this proprietary information or can we up the power or reduce it based off of firmware restrictions without fear of damage? Hehe
i’ve relied almost entirely on usb-wifi dongles because the rpi’s internal wifi chip’s drivers are a pain to work with. i have had success with pci wifi cards as well. have not been able to test against anything else though.
The firmware in these dongles typically is region locked. I know with routers, you have to telnet I to them to tell it to change regions, but this only works if you dont have internet to tell it, “hey, reset your region. You’re set up wrong.”
So if you could tell a dongle to change regions, India, I believe, has the highest allowed transmission power at 4W on the b band (2.4GHz). So you could theoretically transmit at that, even if the firmware limits you to a specific power. Youd have to do some digging into which modules have the highest transmission capabilities… or you could just go for broke and get an SDR and crank up the juice haha
it’s actually a very easy thing to do, google it, also, japan has a whole band which is not accessible anywhere else.
Fascinating! I didnt realise it was so simple! Ok, a little side tracked now, I wonder if it would be possible to change the transmission power of a NINA module now. I’ll have to look into it. Itd be nice to interface from 60m or so to an solar powered arduino 