New smart receiver design. Comments wanted.

[AAH]

I am finally about to relent and create a smart receiver/remote to suit my HE123D and other differential/long range boards.
The boards won't be a direct equivalent to Falcon smart remotes or others but will be made with a slightly different protocol and will allow up to 1600 pixels at 20fps or 800 pixels at 40 fps as per the typical Falcon Player controlled boards. The input power voltage range will be 5-24V. 30A input to 4 7.5A outputs. Essentially no limit on the number of remotes that can be daisy chained. There will be no configuration of the boards required at board level, it will be in the FPP interface.
There will be a test mode that will be a bit more extensive than what I believe is on other smart remotes. This is the reason for the post. With many people running their displays and props at well below 100% brightness I was wondering about having multiple brightness levels as part of the test mode starting at maybe 20% brightness and maybe a couple of steps between that and 100%. I was also wondering whether to have the test mode do the board being tested only or to do that board and all downstream ones.

 

[dkulp]

Why wouldn't you just use the same protocol that FPP already supports?

 

[AAH]

Why wouldn't you just use the same protocol that FPP already supports?

As far as I know there are at least 2 protocols that exist and as far as I know the way in which these protocols work hasn't been made public. I could reverse engineer the protocols but I don't want to use a non public protocol for my own design. The protocol that I came up with is simple and allows a configuration free board setup.

 

[Katekate]

 

[dkulp]

As far as I know there are at least 2 protocols that exist and as far as I know the way in which these protocols work hasn't been made public. I could reverse engineer the protocols but I don't want to use a non public protocol for my own design. The protocol that I came up with is simple and allows a configuration free board setup.

There are four protocols: (that I'm aware of)

1) The original "v1" smart receiver protocol. This is supported by FPP on all three drivers (BBB48String, BBShiftString, and DPIPixels). That said, I'd avoid it at this point as it only supports three receivers and the overhead of the protocol is fairly high.

2) The hinks protocol. This is a config packet only sent went the controller is started up. No idea on the contents. Not supported by anything other than hinks.

3) The Falcon "v2" protocol. This is a config packet sent periodically after the data. It requires flipping the output timing from ws281x to a uart style (start/stop bit,etc..) FPP doesn't support this yet. It's possible that it will be supported on the BBB48String and BBShiftString at some point, but not likely possible with DPIPixels. The config packet is not documented at this point. I believe supports 6 receivers.

4) The FPP "v2" protocol. VERY simple protocol designed to be supported by all three drivers and easily output by the Beagle PRUs and DPI hardware. However, it's harder to output on the processors the Falcon v4's use. (hardware limitations) Anyway, it's very simple, the line is just held low for a short time (but not nearly as long as the ws281x reset) which means "next receiver". Thus, it can technically support more than 6 receivers. The code for this is all in /opt/fpp/src/channeloutput/PixelString.cpp .

Anyway, I'd avoid creating another protocol if you can. It would require bunches of updates to the FPP backend code, the FPP php UI, xLights, etc... The backend code can be the most problematic as there are three different drivers that need to be tested. If the protocol can fit into the normal ws281x data stream (like the #4 above) and can be done entirely in PixelString.cpp, it's a lot easer. If it requires changes to the PRU code to output configuration stuff, that's a TON more work as that's all done in hand tuned PRU assembly.

 

[AAH]

There are four protocols: (that I'm aware of)

1) The original "v1" smart receiver protocol. This is supported by FPP on all three drivers (BBB48String, BBShiftString, and DPIPixels). That said, I'd avoid it at this point as it only supports three receivers and the overhead of the protocol is fairly high.

2) The hinks protocol. This is a config packet only sent went the controller is started up. No idea on the contents. Not supported by anything other than hinks.

3) The Falcon "v2" protocol. This is a config packet sent periodically after the data. It requires flipping the output timing from ws281x to a uart style (start/stop bit,etc..) FPP doesn't support this yet. It's possible that it will be supported on the BBB48String and BBShiftString at some point, but not likely possible with DPIPixels. The config packet is not documented at this point. I believe supports 6 receivers.

4) The FPP "v2" protocol. VERY simple protocol designed to be supported by all three drivers and easily output by the Beagle PRUs and DPI hardware. However, it's harder to output on the processors the Falcon v4's use. (hardware limitations) Anyway, it's very simple, the line is just held low for a short time (but not nearly as long as the ws281x reset) which means "next receiver". Thus, it can technically support more than 6 receivers. The code for this is all in /opt/fpp/src/channeloutput/PixelString.cpp .

Anyway, I'd avoid creating another protocol if you can. It would require bunches of updates to the FPP backend code, the FPP php UI, xLights, etc... The backend code can be the most problematic as there are three different drivers that need to be tested. If the protocol can fit into the normal ws281x data stream (like the #4 above) and can be done entirely in PixelString.cpp, it's a lot easer. If it requires changes to the PRU code to output configuration stuff, that's a TON more work as that's all done in hand tuned PRU assembly.

My protocol out simples all of these. It sounds vaguely similar to the V2 but even easier. Pretty well any pixel controller could generate the data/protocol and the xlights and fpp interface would be fairly much the same as Falcon V2.

 

[dkulp]

The other advantage of going with the v2 protocol is that it's already supported with FPP 5/6/7. A new protocol would only be supported starting with FPP7. Definitely need to consider that. v2 is also supported on the Genius controllers as well so market to sell to would be a bit bigger.

xLights updates are more than just UI updates. The configuration upload stuff also would need to be updated. Again, a new xLights version supporting that would then mean tarageting FPP6/7 only.

Anyway, if you need changes in FPP, you need to start working with Chris and I sooner rather than later to make sure it's acceptable. Changes to PRU code is very sensitive, particularly on BBB48String as there is a bunch of stuff in there specifically to deal with GPIO0 timing problems on the Beagles. Plus, the BBB48String PRU code will likely be entirely re-written in the next month or two to make it work more like the BBShiftString PRU code as it has some issues that makes it not suitable to do pixel counting with the current sensors on the K8-PB. Thus, if there are other considerations that need to be dealt with, I need to know so I can add those to the list.

 

[fuzbat]

Aside from the protocol discussion, which as long as it 'just works' doesn't really affect me.
For testing as long as I can generate 'useful' patterns (a couple of chases, perhaps a chase with every x pixel lit) I'll tend to do anything more once I'm fiddling with my (very limited) sequences. Then again I guess there are props that are designed / not able to run everything at 100% (which isn't something I'm comfortable with) so perhaps the option to limit might be good.

I'd be inclined to have the downstream remotes participate in the testing, ie all lit up and once, but I'm not too phased either way.