Beam camera images/video from RPi to ground via WiFi

[ivogeorg]

Description

1. Figure out the wi-fi range
2. Figure out how to stream video and data from RPi over wifi
3. Set up a headless start of the stream

   Knowledge

   All of these use internet and won't work for our situation.

4. setting up video stream
5. Headless streaming
6. Headless streaming 2

[ivogeorg]

Take into consideration:

1. How we are receiving the stream. The point is to show live video from the cameras. See #5.
2. We do not want to connect to the school WiFi, member of guest. The RPi should use WiFi just as drones are controlled over WiFi from a phone app. The RPi has to create its own network. Can it do so?

[ivogeorg]

Last but not least, we need to budget for the power draw. Heavy data streaming over WiFi can burn our battery power in 15 minutes. @dperry29

[ivogeorg]

This might be relevant: https://www.seeedstudio.com/blog/2021/01/25/three-methods-to-configure-raspberry-pi-wifi/. Apparently, the WiFi config can be done within the RPi Imager before the SD card is written. Not sure if this holds for the case when RPi is itself the wireless hotspot.

[ivogeorg]

Some random finds while looking for the exact thing:

1. This documents the procedure to setup an RPi as a WiFi AP https://thepi.io/how-to-use-your-raspberry-pi-as-a-wireless-access-point/, but that's not quite the case we want. We don't want to forward between WiFi and Ethernet or even another WiFi.
2. This writeup https://github.com/MichaIng/DietPi/issues/2737 is pretty cool, but it is not specifically for RPi.
3. Finally, this forum discussion might be the closest https://forums.raspberrypi.com/viewtopic.php?t=204491 to what we need.

[NotfatPrince]

How to set up non-Internet wi-fi hotspot on RPi hotspot with and without internet access AP without internet

[dperry29]

Last but not least, we need to budget for the power draw. Heavy data streaming over WiFi can burn our battery power in 15 minutes. @dperry29

Yeah this is an issue. We can probably wire in additional batteries for the campus flight, we will have to check the setup on our batt board. (Assuming it works in the first place which im feeling good about) @sschis @dtucker18

[Christopher-Dauchter]

Fortunately we do not need any external guides to get the AP working. The Raspberry Pi Foundation has a full and in-depth write up of the process.

https://www.raspberrypi.com/documentation/computers/configuration.html#setting-up-a-routed-wireless-access-point

I tested it last night, and I could get about 200m with line of sight. I suspect I could get more range, but I ran out of space to walk. There was some delay in communication between the pi and my access device (my phone at the time).

I was hoping that maybe we could hook something up to the IO, so that we can test hardware actuation over ssh or something.

[Christopher-Dauchter]

I also believe we can get much better range by using an external wifi antenna on our ground device.

[Christopher-Dauchter]

Take into consideration:

1. How we are receiving the stream. The point is to show live video from the cameras. See [Record video and stills with RPi Camera #5](https://github.com/MSUSAT/balloonsat/issues/5).

2. We do not want to connect to the school WiFi, member of guest. The RPi should use WiFi just as drones are [controlled over WiFi from a phone app](https://transcendfpv.com/how-to-connect-drone-to-phone/). The RPi has to create its own network. Can it do so?

The Raspberry Pi Foundation specifically mentions an isolated network version of the access point. I got it running nicely last night.

[Christopher-Dauchter]

Last but not least, we need to budget for the power draw. Heavy data streaming over WiFi can burn our battery power in 15 minutes. @dperry29

Yeah this is an issue. We can probably wire in additional batteries for the campus flight, we will have to check the setup on our batt board. (Assuming it works in the first place which im feeling good about) @sschis @dtucker18

I think we might be able to conserve battery by disabling the access point and periodically turning it on every n number of minutes, and checking for a device connection, and if it sees one, then keep the access point open for as long as the device is connected. Since we're running on Linux (I'm assuming were using the Raspberry Pi OS) this should be relatively easy to implement.

[Christopher-Dauchter]

Last but not least, we need to budget for the power draw. Heavy data streaming over WiFi can burn our battery power in 15 minutes. @dperry29

Yeah this is an issue. We can probably wire in additional batteries for the campus flight, we will have to check the setup on our batt board. (Assuming it works in the first place which im feeling good about) @sschis @dtucker18

I think we might be able to conserve battery by disabling the access point and periodically turning it on every n number of minutes, and checking for a device connection, and if it sees one, then keep the access point open for as long as the device is connected. Since we're running on Linux (I'm assuming were using the Raspberry Pi OS) this should be relatively easy to implement.

I just remembered I have a power monitor/data logger. I can get y'all some power data later tonight.

[ivogeorg]

I was hoping that maybe we could hook something up to the IO, so that we can test hardware actuation over ssh or something.

Not sure I get what you mean here, @Christopher-Dauchter

[dperry29]

Last but not least, we need to budget for the power draw. Heavy data streaming over WiFi can burn our battery power in 15 minutes. @dperry29

Yeah this is an issue. We can probably wire in additional batteries for the campus flight, we will have to check the setup on our batt board. (Assuming it works in the first place which im feeling good about) @sschis @dtucker18

I think we might be able to conserve battery by disabling the access point and periodically turning it on every n number of minutes, and checking for a device connection, and if it sees one, then keep the access point open for as long as the device is connected. Since we're running on Linux (I'm assuming were using the Raspberry Pi OS) this should be relatively easy to implement.

I just remembered I have a power monitor/data logger. I can get y'all some power data later tonight.

That would be awesome!

[ivogeorg]

I think we might be able to conserve battery by disabling the access point and periodically turning it on every n number of minutes, and checking for a device connection, and if it sees one, then keep the access point open for as long as the device is connected. Since we're running on Linux (I'm assuming were using the Raspberry Pi OS) this should be relatively easy to implement.

We want to stream a live view of the 4 cameras (assuming they arrive in time :D), so this method of conserving is not viable. For the high-altitude flight, we won't need the WiFi. OreSat is using WiFi to LEO but they are using serious amplification. Anyway, the WiFi is for the lawn demo on Dec 2.

[Christopher-Dauchter]

I was hoping that maybe we could hook something up to the IO, so that we can test hardware actuation over ssh or something.

Not sure I get what you mean here, @Christopher-Dauchter

Perhaps having an LED or servo on IO, so that when we do the 50m test we can send a command and see the results.

[Christopher-Dauchter]

I think we might be able to conserve battery by disabling the access point and periodically turning it on every n number of minutes, and checking for a device connection, and if it sees one, then keep the access point open for as long as the device is connected. Since we're running on Linux (I'm assuming were using the Raspberry Pi OS) this should be relatively easy to implement.

We want to stream a live view of the 4 cameras (assuming they arrive in time :D), so this method of conserving is not viable. For the high-altitude flight, we won't need the WiFi. OreSat is using WiFi to LEO but they are using serious amplification. Anyway, the WiFi is for the lawn demo on Dec 2.

This was mainly in response to power concerns during the lawn test. Depending on the resolution/fps we might be able to burst send video data, and then go into hibernation for a little bit, then burst again.

[ivogeorg]

Perhaps having an LED or servo on IO, so that when we do the 50m test we can send a command and see the results.

I get it. I am defaulting to the vertical 50 m perspective and was wondering how you would see the LED w/o an internal camera/sensor. Anyway, I hear you.

In fact, we might want to keep the WiFi option, including your idea of monitoring the connection status, as a secondary (or why not primary) headless admin/control before liftoff and after touchdown. We can start the WiFi on power-on and admin over it, keeping the USB2UART as a backup. What do you think, @Christopher-Dauchter?

[Christopher-Dauchter]

I think we might be able to conserve battery by disabling the access point and periodically turning it on every n number of minutes, and checking for a device connection, and if it sees one, then keep the access point open for as long as the device is connected. Since we're running on Linux (I'm assuming were using the Raspberry Pi OS) this should be relatively easy to implement.

We want to stream a live view of the 4 cameras (assuming they arrive in time :D), so this method of conserving is not viable. For the high-altitude flight, we won't need the WiFi. OreSat is using WiFi to LEO but they are using serious amplification. Anyway, the WiFi is for the lawn demo on Dec 2.

Is Wifi amplification not a possible route for us? I feel like a wifi amplification board might be easier to implement vs. building and entire I2C/some other direct line communications system/demodulation/modulation/amplification board. (I know easy isn't entirely the point of the project, just exploring all our options :)

[Christopher-Dauchter]

Perhaps having an LED or servo on IO, so that when we do the 50m test we can send a command and see the results.

I get it. I am defaulting to the vertical 50 m perspective and was wondering how you would see the LED w/o an internal camera/sensor. Anyway, I hear you.

In fact, we might want to keep the WiFi option, including your idea of monitoring the connection status, as a secondary (or why not primary) headless admin/control before liftoff and after touchdown. We can start the WiFi on power-on and admin over it, keeping the USB2UART as a backup. What do you think, @Christopher-Dauchter?

That is very possible. Some of the literature I've read has suggested such an option.

As of right now I have the Pi set up to autostart the network, and broadcast with SSH capabilities.

As for the LED idea, I was actually thinking of using good ol' analogue binoculars to see if it worked properly.

[ivogeorg]

Is Wifi amplification not a possible route for us? I feel like a wifi amplification board might be easier to implement vs. building and entire I2C/some other direct line communications system/demodulation/modulation/amplification board. (I know easy isn't entirely the point of the project, just exploring all our options :)

@Christopher-Dauchter, worthy discussion! Right now we are on a short-term schedule for flight on Dec 10. At this point, extra complexity (especially de-novo design) is to be avoided. We need a successful flight for many reasons. After that, we will essentially re-launch the project and start with systematic design.

The amplified WiFi would be perfect for the May 2022 goal of the Balloonsat Hackathon, because it will lower the bar of entry for the participants who don't have ham radio setups. Let's discuss at meeting.

[dperry29]

Is Wifi amplification not a possible route for us? I feel like a wifi amplification board might be easier to implement vs. building and entire I2C/some other direct line communications system/demodulation/modulation/amplification board. (I know easy isn't entirely the point of the project, just exploring all our options :)

@Christopher-Dauchter, worthy discussion! Right now we are on a short-term schedule for flight on Dec 10. At this point, extra complexity (especially de-novo design) is to be avoided. We need a successful flight for many reasons. After that, we will essentially re-launch the project and start with systematic design.

The amplified WiFi would be perfect for the May 2022 goal of the Balloonsat Hackathon, because it will lower the bar of entry for the participants who don't have ham radio setups. Let's discuss at meeting.

Yeah this makes a lot of sense. The amount of HAMs out there may be pretty limited for this application.

[ivogeorg]

@Christopher-Dauchter A link that might be useful: https://www.tomshardware.com/how-to/stream-live-video-raspberry-pi

[ivogeorg]

@Christopher-Dauchter found this guide https://elinux.org/RPi-Cam-Web-Interface

[ivogeorg]

@dperry29

From @Christopher-Dauchter:

MSUSAT_POWER_LOG_15_11_2021_TEST_01.xls

Relevant to #17