News:

LATEST RELEASE:  FPP 7.5 - Download from here - https://github.com/FalconChristmas/fpp/releases/tag/7.5

+-+-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Site Stats

Members
Total Members: 16446
Latest: josh19002
New This Month: 17
New This Week: 3
New Today: 1
Stats
Total Posts: 132570
Total Topics: 16437
Most Online Today: 145
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 0
Guests: 134
Total: 134

P9-28 and P9-29 not work

Started by windaube, April 13, 2024, 04:28:03 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

windaube

Hello,

To start, I decided to build my 48-output controller with a BBB. 
I prepared an SD card using the "Raspberry Imager" tool, FFP 7.5 for BBB. 
Once booted from the SD card, I installed FPP 7.5 on the eMMC memory. 
I declared a virtual EEPROM in RGB123, model RGBCape48F, with 50 pixels per output for the 48 outputs.

When I test the outputs with the testing tool, everything works correctly. 
The output mapping is perfect EXCEPT for two outputs. 
Output 35 > pin P9-28 and output 36 > pin P9-29 are not working.

Here is the behavior with the pixel testing tool :
If I select "output 35" with start channel 5101-5250, I get nothing on output 35 or 36.
If I select "output 36" with start channel 5251-5400, I get nothing on output 35 or 36.
If I select start channel 5101-5400, I have two outputs that start functioning at the same time. 

It seems there might be a conflict on pins P9-28 and P9-29. I'm not using the BBB's Wi-Fi version, so these two pins should normally be free.

windaube

Hello, 

finally I found the solution to my problem. 
I had to modify the file /opt/fpp/cape/bbb/string/RGBCape48F.json and replace the pins p9-28 and p9-29 with p9-21 p9-22. 
I tried with version 5.5 of FPP and the bug was already present! 

So cool to buy licenses for $30 for software that isn't even tested.

AAH

I make boards that use the same pinout configuration and same rgbcapeF library and don't have any issues. I think that it's a config issue at your end rather than a FPP bug. There is a channel remapping section which has caused me issues in the past and that may be where you are having problems.

Poporacer

Quote from: windaube on April 14, 2024, 10:35:49 AMSo cool to buy licenses for $30 for software that isn't even tested.
There are literally dozens of boards out there that work just fine, I don't think it is a software problem.
If to err is human, I am more human than most people.

MikeKrebs

Quote from: windaube on April 14, 2024, 10:35:49 AMfinally I found the solution to my problem.
I had to modify the file /opt/fpp/cape/bbb/string/RGBCape48F.json and replace the pins p9-28 and p9-29 with p9-21 p9-22.
How did you find the solution?

MikeKrebs

Quote from: Poporacer on April 14, 2024, 08:57:15 PM
Quote from: windaube on April 14, 2024, 10:35:49 AMSo cool to buy licenses for $30 for software that isn't even tested.
There are literally dozens of boards out there that work just fine, I don't think it is a software problem.
So then you are saying his hardware is defective with some crossed traces?

Poporacer

Quote from: MikeKrebs on April 14, 2024, 09:09:58 PMSo then you are saying his hardware is defective with some crossed traces?
I have no idea what the problem is, but AAH, Wally's lights, and Scott Hanson, to name a few, have all made controllers for several years now and they have all worked with FPP and there are probably hundreds of them out there. That is why I am saying his problem was NOT due to untested software as he claimed. 
If to err is human, I am more human than most people.

dkulp

He doesn't say where he got his board from or if he designed it himselft or what.   However, the schematics at http://rgb-123.com/wp-content/uploads/2016/03/RGBCape48F.pdf clearly show it using P9-28 and P9-29 so the pinout in FPP is definitely correct per their schematics. 
Daniel Kulp - https://kulplights.com

windaube

I apologize, I acknowledge that I was a bit mean in my response.

It's really strange, the .img is flashed correctly, I don't touch anything in the original configuration, yet these two original ports don't work. 
The only nuance is that I own a BBB 'element 14' but it's identical to the original BBB.


Poporacer

Quote from: windaube on April 15, 2024, 10:11:33 AMI apologize, I acknowledge that I was a bit mean in my response.
LOL, apology accepted
What hat or cape are you using, that was never mentioned.
If to err is human, I am more human than most people.

Poporacer

An interesting disclaimer on the Element 14
You cannot view this attachment.
If to err is human, I am more human than most people.

dkulp

That's compared to the original Beaglebone, not the Beaglebone Black.  
Daniel Kulp - https://kulplights.com

windaube

Quote from: Poporacer on April 15, 2024, 02:18:40 PMWhat hat or cape are you using, that was never mentioned.
For now, none, I'm simply testing on a 'table', but I declare a virtual RGB123 EEPROM. 
I'm going to manufacture a simplified clone of the RGB123, without UART, without OLED, without buttons, without clock signal, without EEPROM. Just 48 outputs, 16 outputs with SN74HCT125, and the other 32 with RS485 drivers.



Quote from: Poporacer on April 15, 2024, 03:13:04 PMAn interesting disclaimer on the Element 14
I'm not surprised by this line, it's well known that certain pins become unavailable depending on the options. 
It seems that the WiFi version of the BBB removes 4 or 5 pins. 
When I compare my Element 14 BBB with photos of the original, I don't see any difference. 
I thought it was simply a manufacturer who had bought the rights to manufacture it without any modifications, but evidently not

Maybe one day I'll test it with the original. 
I remain cautious with the BBB; it seems to have been manufactured for several years, and I have doubts about the future of this product. Perhaps in 2 or 3 years, it will be unavailable. I don't know



Powered by EzPortal
Powered by SMFPacks Menu Editor Mod