FPP 7.0 Released!

[rayhjr]

• Ability to "Add" and provision network interfaces that don't yet exist. Should allow provisioning of wlan0 adapters when only eth0 are available at first boot.

How does this work? I have a BBB based controller currently attached with eth0 but don't see how to set this up. Is it only at first boot? Eventually it will have a adapter plugged in and will sit in the yard to work wireless.

On the Network page, there is a new "Add New Interface" button at the bottom.  Click that, type in wlan0, and it should create a new wlan0 interface in the list that you can then configure. 

I was not seeing it as I was on Basic Interface Level. Changed to Advanced an BINGO. Thanks.

[ChuckM]

I just upgrade and following this thread to select advance and the add wlan0. This does not recognize the USB wireless adapter that I have used for all my FPP connections it the past. What am I missing?

[JonD]

I just upgrade and following this thread to select advance and the add wlan0. This does not recognize the USB wireless adapter that I have used for all my FPP connections it the past. What am I missing?

Raspberry Pi FPP devices could be trying to load 64-bit network drivers instead of 32-bit.  FPP would not load my USB wireless driver either, and I had to modify my config file to force it to use 32-bit drivers instead.  If your problem is the same, it is a known issue that is being looked into.

[ChuckM]

I found if I changed to use Linx drivers it worked.

[JonD]

Glad that worked for you.  I tried that as well, but using Linux drivers it still booted "not found" for me.  I had to modify my \boot\config.txt file and add arm_64bit=0 to the very last line and reboot.

[Sawdust]

I found if I changed to use Linx drivers it worked.

I found if I just connected to eth0, wlan0 connected. Maybe the reboot doesn't allow external to work....no network connect, no path to driver. Connecting eth0 gives it the external path needed.

I'm needing to hard boot all 7.0 upgrades.  Pi 2 ,3, 4 & Zero.  Pocket Beagle and BBB's

[deanathpc]

Full OS upgrade done here.  All three Raspberry Pi's went without a hitch.  I have a Beagle Bone Black to get to yet and not sure when that will happen.  Can report on that when that time comes.

This new version seems to be running great on each Pi though.  Will be doing more testing soon.

[Bos Lights]

Is this a bug in FPP version 7.0 where the color codes are incorrect?

Pre re-imaging on 5.5

• Cape type:  PiHat
• Pixel strings output color order set to BRG

Post re-imaging on 7.0

• Cape Config:  PiHat
• PiHat output color order set to GBR to get the same result.

[Poporacer]

Is this a bug in FPP version 7.0 where the color codes are incorrect?

No, it was a bug that has been in FPP for quite a while but was fixed. The GBR and BRG color orders were wrong. We were surprised that no one had caught it yet. We thought that either nobody was using GBR or BRG pixels, or they did not know what color order their pixels really were and were just using whatever worked correctly.

[k6ccc]

We thought that either nobody was using GBR or BRG pixels, or they did not know what color order their pixels really were and were just using whatever worked correctly.

I suspect the latter is the case.  Often you don't know what the color order REALLY is in the pixels, so set to RGB, see what's wrong and correct, or just try all the combinations until you find the one that comes out right.

[Poporacer]

Often you don't know what the color order REALLY is in the pixels, so set to RGB, see what's wrong and correct, or just try all the combinations until you find the one that comes out right.

That is what I thought as well. Most vendors don't publish the actual color order. But when I saw the code, it was obviously an error....

[Bos Lights]

Thank you Poporacer and k6ccc! Good to know 😊.

[Poporacer]

Thank you Poporacer and k6ccc! Good to know

When I found the bug, I looked to see when that bug was actually introduced before I fixed it and it looks like it was an error from the very beginning of the channel code....
But thanks a million for bringing it to our attention!

[AAH]

Just about to start redoing some of my manuals so grabbing the latest fpp7 images and will then do any updates and while grabbing I noticed "PHP processing was split from the Apache HTTPD service. Due to this change, older versions of xLights cannot upload files to FPP7. "
What version/s of xlights are considered older? I have a prehistoric pre Sean, David, Keith etc version that's about 10 years or so old somewhere so I can imagine that classes as old but is older in the 2023.01 range or where is the cutoff? 

[dkulp]

Just about to start redoing some of my manuals so grabbing the latest fpp7 images and will then do any updates and while grabbing I noticed "PHP processing was split from the Apache HTTPD service. Due to this change, older versions of xLights cannot upload files to FPP7. "
What version/s of xlights are considered older? I have a prehistoric pre Sean, David, Keith etc version that's about 10 years or so old somewhere so I can imagine that classes as old but is older in the 2023.01 range or where is the cutoff?

I believe the cut off is 2023.06, might be .07.