search

PiSupply / IoTLoRaRange

Repository for all of the IoT LoRa Range of Products
65 stars 11 forks source link

Use Alternate OS for Standalone Gateway #6

Closed ryanteck closed 5 years ago

ryanteck commented 5 years ago

This is to discuss with Beta Testers & Others the software for the standalone gateway.

With the release of Debian Buster a majority of bits did break and while they are fixed now I have noticed quite a few issues.

As stability is the key concern for this I have investigated the potential for switching to Ubuntu.

Primarily as a spur on from issue https://github.com/PiSupply/iot-pi-gen/issues/2 . The two 4G Modules we have didn't seem to want to work with raspbian or kept having intermitternt issues with connection.

Trying with Ubuntu Server worked instantly once the packages were installed.

Test List

This all has to be tested before a switch can be made.

Pros & Cons

Initially the main Con would be that it doesn't support Original Raspberry Pi's. However as this is primarily for the standalone gateway this won't be an issue as I believe we're planning on shipping with CM3+ 8GBs. Along with this there might be slightly more work to setup Ubuntu to Compile.

However just at initial lookings there's many benefits of moving to Ubuntu Server including:

Note

We will still be providing a template for balena however most customers that are using balena will likely be using their own images / templates. This image will be pre-flashed onto all the CM3+s leaving the factory for those wanting to buy something they can just login, copy keys and get going.

ryanteck commented 5 years ago

The EC25-E and SIM7100 both worked straight away with Ubuntu. Configuration just required one command to set the sim provider.

keyboard-magpie commented 5 years ago

Ubuntu server and the 40pin breakout. How's that going to go, in general? Presumably most GPIO stuff is fairly portable across?

shawaj commented 5 years ago

@monglet that was my first thought too - whether it would break support for existing hats

However, as you say @ryanteck the biggest concern is stability of the core components. If hats are a bit more fiddly it's not the end of the world IMO. Stability should take precedence

AmedeeBulle commented 5 years ago

Is there any statement on term of support for Raspbian Stretch? From a pure Debian perspective, Buster is still development and Stretch the current stable release which will be supported until June 2022...

Although I believe 64bits is the way to go these days, I had variable success with mainline kernels on Raspberry Pi when it comes to "hardware management" (GPIO, CPU throttling, ...), so I tend to stick to the official Raspbian on my Pies...

ryanteck commented 5 years ago

@shawaj I think we can do a check with the most important hats to us.

I don't see Pijuice not working and I can test that out tonight / tomorrow

@AmedeeBulle That's quite a good point actually. I've just done some googling.

It looks like packages are supported for the same time as in the main debian repositorys. However it looks like kernels and some RPi supported packages are not maintained once they switch. As RPi are now shipping buster it doesn't look like stretch will get any updates out of them. So Ubuntu would be a good move for the better software support.

As for hardware management I'll be testing that out next. If I can't get the gateway to work on it at all then we won't be able to switch.

shawaj commented 5 years ago

@ryanteck yeah, whatever you think is best really. I think it's probably easier to bring support for X HAT to a stable platform than to bring stability. If that makes sense

keyboard-magpie commented 5 years ago

Thinking through HAT compatibility. The standalone is presumably going to spend most of it's time in the ip67 case. PiJuice would be excellent for UPS behaviour. i2c hats would be easier than SPI on ubuntu. Wondering about display HATs too, for stats display. (sorry, typing my thoughts out loud!)

ryanteck commented 5 years ago

@monglet SPI and I2C both seem to be fully working under Ubuntu as standard as these just show as linux devices. It'll be more if there's reliance on dtbs and gpio libraries.

Already got the gateway hat working with a 3B+ with no modifications required to the software. Just need to re-test on CM3+

I'll test pijuice tomorrow however expect no issues.

ryanteck commented 5 years ago

All Lora Gateway Hat Tests completed, 100% Working.

Just need to test on CM3+.

AmedeeBulle commented 5 years ago

2 Qs:

ryanteck commented 5 years ago

To reset the concentrator we've been using /sys without issue. The PHP controller calls the bash script to do this on reboot.

As for throttling I haven't investigated. I suspect it is the same as Raspbian where it will throttle with heat.

I haven't actually had to set the GPU Clock slower which I have set as default in the Raspbian image. However I also have the packet forwarder use a slightly slower SPI speed for reliability. (To ensure less issues across all devices).

I'll test to see if RPi.GPIO works.

I also need to buy a Sim topup @shawaj to confirm the LTE modules still work (my 200Mb is out of free data).

ryanteck commented 5 years ago

Pi Juice works with little modification on Ubuntu. The only thing was a permissions error on a command but with chmod easily fixed that.

However RPi.GPIO doesn't seem to want to work. I'll see what steps are required to get it to work.

Screenshot from 2019-07-02 15-34-29

Otherwise all tests are indicating Ubuntu is the better option so far.

shawaj commented 5 years ago

Sounds good!

AmedeeBulle commented 5 years ago

RPi.GPIO is not necessary -- /sys is good enough... (I have somewhere a python library which emulates the basic functionalities of RPi.GPIO, but that's not a even useful here)

This project is more about having an (open) appliance, people who want to do more are better with a plain RPi / LoRaWan hat...

ryanteck commented 5 years ago

Yeah, I believe it'll work but it's just whatever signature it's looking for to confirm it's running on a RPi is failing.

So far I think it's all confirming a change to Ubuntu for the Standalone Gateway. The current image for HATs will stay as it is along with being actively maintained and updated.

The main thing left is to investigate how to create our own ubuntu images and confirm if we need to use Core or if we can use Server

ryanteck commented 5 years ago

New Update

So Ubuntu Core might not be possible but is waiting on clarification to confirm. As essentially we would need to pre-load the software / snaps into our own Ubuntu Image this may not be then allowed to be re-distributed without paying licensing fees. However I am waiting on clarification.

Also when setting up on my CM3+ I found that the Ubuntu Core & Ubuntu Server Images don't have the latest firmware for the Raspberry Pi so it refused to boot, however while I could re-package the boot files using a guide Ubuntu provide for us to then include in our image. This could count as a change which once again falls into the licensing fee category above.

For this project from talking to a few people having some kind of method to ensure reliability and such is key, primarily the ability to remotely update the gateways.

One other potential route I'm investigating is Open Balena which would allow us to setup our own Basic Version of Balena. Each gateway would get programmed with the OS image and then when powered on it would contact a server that we would setup to download and configure the gateway.

The main downside is that we would need to setup our own server for the items to download from but otherwise could actually be an even better route than Ubuntu

ryanteck commented 5 years ago

I'll get the balena option tested out this week if we don't have clarification from Canonical with the issues we've got of using Ubuntu Core

ryanteck commented 5 years ago

Thank you to all those who have provided feedback.

I think it will actually be best to try to stick to Raspbian so will work on fixing the 4G Module bugs with that. This is primarily as much to avoid duplicating lots of work.

However it will be where we look at packaging our code into basic APT packages on potentially our own APT repository. That way gateways can be updated with a one click button instead.

Support will still be given for people wanting to use normal Balena.