K16A-B + SRx1 V4.00

[ssmith512]

Greetings All!

New here.  Been reading, watching and learning everything I can about this hobby for the past month and finally got to the point where I thought I was comfortable and understood the basics.  So last week I purchased my first controller, a K16A-B, an SRx1 V4.00 rx board all from Kulp Lights (which included an SD card with FPP V7.5 already installed) a string of 12V 50 pixels and a 12V power supply so I could test and play around in xLights and FPP to verify I did in fact understand the basics, before I purchase "everything else" I want/need for a Halloween/Christmas show.

Initial install, configuration of the K16 and FPP and setting up in xLights was flawless.  I created a simple sequence in xLights (just a single strand of 50 pixels with a red color chase), and uploaded through FPP connect.  Used the visualizer to assign the string to port 14.  Did all that stuff - and played the sequence through FPP and it worked perfectly.  No issues.  Then I tried the rx board.  Changed the output to port 17 in the visualizer, reuploaded the configuration - verified the settings in FPP.  Rendered the sequence again and reuploaded through FPP connect.  Tried playing the sequence again through FPP and I get nothing.  No data LED's on the rx board ever light up.  I tried a different cat5 cable, nothing.  I tried ports 21, 25, 29 (always changing configuration in the visualizer, reuploading) and always nothing.  I can press the test button on the RX board and I get output to the pixel string.  Just when I try to play a sequence, it is as if the K16 is not sending data to the rx board.  I have tried setting the rx board rotary dial to "A", tried "0" and tried "4".  I have tried setting it to Standard rx and Smart rx in the visualizer.  Nothing I do, no matter the configuration I try, the pixels will not light up if connected to the rx board.  Pixels will light up on any port on the K16 with no problem. See pics for some references.  Again, this is my first ever pixel controller, rx board and first go with xLights and FPP.  I thought I understood the basics but I guess not LOL!  I am at the end of my limited knowledge with the hardware and software and am seeking help.  Thanks in advance

[ssmith512]

OK, updated with new information:

Did some elimination style diagnosing.  Previously I was pretty much doing all my testing on port 17.  Now, the rx board rotary dial is set to "0".  All ports work with the following exceptions:  If lights are plugged into Ports 17, 21, 25 and 29, the lights do not work at all.  No data led lights up.  If plugged into port 18, all pixels will light up full white when I play the test sequence from FPP and stay lit full white even if I stop the sequence in the FPP player.  So I think at this point I may have a defective rx board?  

[tbone321]

It could be a bad board or it could be that the configuration is incorrect.  Try setting the board ID to zero and set the type to standard in the Kulp configuration.  This is the most basic configuration and should work.  Unlike the Falcon controllers, the Kulp controllers do not send any data to the remotes unless a show is playing which makes troubleshooting a bit more difficult since the data lights don't just light up when the remote is plugged in.  If you identify the board as an intelligent board, then you also have to configure the Kulp controller to send the data that way so that it sends the data to the correct board and the configuration you are showing doesn't look kike that is how it is set up.

[ssmith512]

UPDATE:  Mr. Kulp is trying to help me....updated FPP to V7.5-4.  I was on V7.5.  That fixed the issue with port 18, but ports 17, 21, 25 and 29 remain dead.  When pixels are plugged into those ports and a sequence is playing, data led's #2, 3 and 4 are lit up.  Data led #1 is not lit.  I also flashed the eeprom (I was on V2.0 - reflashed it with V2.0), but that didnt seem to do anything.  Almost there.

[ssmith512]

It could be a bad board or it could be that the configuration is incorrect.  Try setting the board ID to zero and set the type to standard in the Kulp configuration.  This is the most basic configuration and should work.  Unlike the Falcon controllers, the Kulp controllers do not send any data to the remotes unless a show is playing which makes troubleshooting a bit more difficult since the data lights don't just light up when the remote is plugged in.  If you identify the board as an intelligent board, then you also have to configure the Kulp controller to send the data that way so that it sends the data to the correct board and the configuration you are showing doesn't look kike that is how it is set up.

Thanks.  Board ID is set to zero.  I still have the board configured as a smart rx "A" type KPP2.0 in the visualizer in xlights.  Only ports 17, 21, 25 and 29 are "dead".  All other ports are working as expected.

[tbone321]

I would ignore the visualizer for now and set it manually as a standard remote and try it that way.  You may also try a different cable between the controller and the board.  Did you also try both ports on the remote board.  A bent pin or a bad cable can also cause this issue.  It could also be a bad connection on the boards communication chip and there's not much you can do about that.

[ssmith512]

I would ignore the visualizer for now and set it manually as a standard remote and try it that way.  You may also try a different cable between the controller and the board.  Did you also try both ports on the remote board.  A bent pin or a bad cable can also cause this issue.  It could also be a bad connection on the boards communication chip and there's not much you can do about that.

Thanks.  I have tried a different cat5 cable, same results.  Set rx board to standard and same results.  The result is the same no matter what RJ45 port I have the cable plugged into on the K16A-B.......The first port on the RX board (which would be port 17, 21, 25 or 29 depending on which RJ45 jack I am plugged into on the K16) will not light up the pixel string.  Ports 2, 3 and 4 on the rx board all work all the time.  I have ordered another rx board from Kulp to try.  Either the K16 is not sending data to port 1 on the rx board or the rx board is not processing that data correctly.  Hopefully a new rx board will help determine that.

[tbone321]

It would be highly unlikely that all 4 external port connectors on the controller would have a bad port, especially if it is the same port on all 4.  I would say that you have a bad differential adapter board.  Good luck with the new one.  I had a nearby lightening strike take out 3 of mine with similar issues.  I was able to repair one of them but it was such a PITA, I will just replace the others.

[ssmith512]

It would be highly unlikely that all 4 external port connectors on the controller would have a bad port, especially if it is the same port on all 4.  I would say that you have a bad differential adapter board.  Good luck with the new one.  I had a nearby lightening strike take out 3 of mine with similar issues.  I was able to repair one of them but it was such a PITA, I will just replace the others.

I agree.  Mr. Kulp has given me another thing to try later this evening.  

[dkulp]

It would be highly unlikely that all 4 external port connectors on the controller would have a bad port, especially if it is the same port on all 4.  I would say that you have a bad differential adapter board.  Good luck with the new one.  I had a nearby lightening strike take out 3 of mine with similar issues.  I was able to repair one of them but it was such a PITA, I will just replace the others.

Actually, in this particular case, it makes a lot of sense and it provided the key to understanding what was going on.   The new K16 is different from the other beagle controllers in that its wired for bi-directional communication with the receivers.   Instead of an individual 4 channel differential sender for each of the four RJ45's, there is one for "port 1" on each and that's controlled by a pin on the K16 to put it in "send" or "receive" mode.   FPP 7.x doesn't know how to control that direction pin (so its floating, sometimes works or it might not).     Anyway, pushed another fix to the FPP 7.5 branch to configure the pin so I believe it should now work.

As and FYI:  the K16 now will get eFuse triggers from the FIRST Falcon v5 receiver on the chain.   Haven't managed to get the rest of the chain working yet.  It also will reset the efuses when output is started.  xLights hasn't been updated yet to allow selecting the v4/v5 protocol for the K16, but you can go to the page in FPP and reset it and the eFuse alerts can work.  

[tbone321]

Thanks for releasing that information.  Is that change also going to be implemented on any new K8's down the road?  

[ssmith512]

Can't thank Mr. Kulp enough for taking the time to help a complete newbie like myself.  FPP V7.5-5 resolved my issue and all is working as expected.

Thanks!!