F8B+

[dkulp]

Part of my show has outgrown the F4B that I've used the last two years.  I need at least one more output, likely two, for this year.   I also would prefer two DMX outputs at that location.  (I could then get rid of a Komby serial adapter that's currently there)


One option is to jump to the F16B, but that is much larger than I need and really wouldn't fit into the CG500 that I'm currently using.  Instead I managed to convince Dave to let me see the F4B schematics and decided to try to design my own board.  I've attached preliminary drawing.   Basically, it's an F8B providing 8 fused pixel ports.   In addition to that, it has 3 RJ45 ports.   Those are configured as follows:
Top port:  this is a differential output of ports 9-12.   Thus, if you have the falcon differential board, there is 4 more strings
Middle port:  this will be configurable in FPP (I may need the Captains help on this) as either 4 more strings for the differential board OR 4 universes of DMX OR 4 universes of PixelNet
Bottom port: this is also configurable as 4 more strings OR 4 DMX or 4 PixelNet.  The restriction being that we cannot do DMX on one and PixelNet on the other.


So basically, if you don't need DMX/PixelNet, you would get 8 local strings and 12 "remote".   


Anyway, I definitely need Dave or someone to take a close look at it.  I've NEVER EVER EVER designed a board before.   I installed Eagle for the first time specifically to attempt this.   I'm learning as I go on this.  Eagle doesn't have the parts in the normal library for a bunch of things so I grabbed stuff that "looked right."   I'm also a bit unsure on the wiring of the RJ45's for the differential board.  They need double checking.  You'll also see the bottom left is completely empty.   I may re-introduce the RTC there and/or a power button.   Haven't decided.   Not something I would really use, but I could just not populate it.  Probably better than blank space.  I was kind of hoping for an additional RJ45, but not sure where it would fit.   I also haven't started at all on the silk screen layer.    I've stuck the eagle project in my dropbox if anyone wants to look:


https://www.dropbox.com/sh/v7spzway2bxzx8b/AADOzFXn1H-on_yi5eF2r1Dea?dl=0


Anyway, would anyone else be interested in one (or more)?  Kind of trying to gauge if there is enough interest for a group buy or similar or do I just order some prototype boards for myself. (in which case I won't care at all about the silk screen)     Right now, it's JUST under the 10cm x 10cm size of ordering.

[AAH]

Hi Dan
A few things.
Firstly good luck with your 1st design.
-You haven't left any room on silkscreen for nice big text for the + and - on power input and voltages for jumpers.
-As the board is only part routed I imagine that the missing gnd is yet to be routed.
-changing from dmx to pixel output isn't just a config change. DMX uses a differential output that needs an RS485 IC to provide the correct voltages and drive
-I would always have an electro capacitor as well as a ceramic on both input and output of regulator.  You have a 33uF cap in what looks to be the footprint of a little ceramic cap.
-if using an OKI78 series regulator the footprint is too small. It is larger than TO-220
-you may have clearance issues trying to fit RJ45 connectors between pcb and BBB
-your pcb standoffs look a bit small. There only looks to be enough room for maybe 3mm diameter heads compared with about 6mm required for 3mm screws

[David Pitts]

Dan actually has 12 RS-485 circuits on his board and will be relying on a software switch of the PRU code to switch those eight ports between pixel data or serial data. In either case the data whether pixel data or serial data will run through the RS-485 drivers.   

[dkulp]

-You haven't left any room on silkscreen for nice big text for the + and - on power input and voltages for jumpers.-As the board is only part routed I imagine that the missing gnd is yet to be routed.

Actually, it is fully routed.   I just screen shotted it before the pour as its very hard to see the traces.   I've attached top and bottom layers.  There aren't a lot of traces on the bottom (I tried to keep as much on top as I could) so the bottom is very very "blue".   The Eagle ERC and DRC checks don't find anything wrong.   

-changing from dmx to pixel output isn't just a config change. DMX uses a differential output that needs an RS485 IC to provide the correct voltages and drive

As Dave mentioned, there are 3 quad differential output chips on there providing 12 lines.   The PRU code will be used to figure out what data goes where.

-I would always have an electro capacitor as well as a ceramic on both input and output of regulator.  You have a 33uF cap in what looks to be the footprint of a little ceramic cap.
-if using an OKI78 series regulator the footprint is too small. It is larger than TO-220

This is taken right off the F4B schematics.  (and matches my visual inspection of my F4B)   Blame Dave.   At the very least, it works.  I can increase the footprint a bit since the F4B does use the OKI thing.  That's not a problem.

-you may have clearance issues trying to fit RJ45 connectors between pcb and BBB
-your pcb standoffs look a bit small. There only looks to be enough room for maybe 3mm diameter heads compared with about 6mm required for 3mm screws

The RJ45 goes on top, the Beagle on the bottom.  That's not an issue.   I'll try and move the standoff holes around a bit.  Looks like I'll need to shift the rj45s slightly for the bottom right.   That's a pain. 

Thanks for the look!
Dan

[Blickensderfer]

Dan,


Do you know what the estimate cost of the board will be?  populated or bare?


Dan

[AAH]

  The screenshots show an issue which may or may not be an issue. There is a thermal relief created around the input power connectors. This means that for something like about 15thou there is only 4 15thou (?) tracks providing the 30A of potential power. I'm assuming 30A as I'm guessing that 30A 6.35mm(or similar) sized terminals are being used.
  I couldn't easily trace the 5V connection from the reg through the IC's but it looks to be something like about 15 thou all the way. As there's potentially reasonably high pulse currents when driving into dmx or pixel cabling I would make the 5V line something like 40 or 50 thou where possible.

[dkulp]

I managed to spend some more time on this last week and redid a bunch of things.  I'm much happier with this.   I re-routed a bunch of things to fix a lot of spacing issues, particularly with Elecrow's cam settings.   I increased the size of the 5V power trace to the IC's up to 56mil which should be OK.   However, I ran the numbers for the BBB + 3 differential outputs chips + oct buffer + edimax wifi and it looks like I need ~1.47amps which is WAY too close for comfort for the 1.5amp OKI78 things.    Thus, I'm still kind of looking at other options that can provide 2amps instead.   The F16B solved it by using 2 OKI78's, but I'm trying to avoid that if possible.  Thus, for right now, the board has a couple extra capacitors around the that part as I'm not sure what I'm going to use there yet.     The 580-78SR-5/2-C I'm looking at for prototyping doesn't need any capacitors there, but a couple other options do.   


Pricing:  I ordered 10 prototype boards from electro for less than $50 delivered.   That's with 2oz copper.   Thus, the board itself would definitely be under $5. Obviously, as qty goes up, cost goes down.  I think qty 100 brings it down to about $2/board.


BOM cost:  I've played around with the BOM on DigiKey and using a MEZD71202A-G for the power (not in stock though), the compete BOM cost would be $53 for a single board.   Other power options are likely about $5 more.   However, a single board doesn't hit the qty discounts for anything.   Putting BOM's for 10 into my cart drops the cost to $44 and 100 drops to $38.     That said, there are definitely things you don't need to populate if you aren't going to use them.  For example, if you don't need the differential outs for the strings (no differential receiver board), you can save some money by not adding that IC and the RJ45 socket for that.  If you just use 5V pixels, skipping the whole power things can also save a chunk.


FPP updates:  I have some preliminary updates on my f4b-dmx branch.   Somewhat untested though.   For now, I've been calling it an F8-B since that's what my initial goal was.  But it has kind of expanded to drive up to 20 strings (8 "local", and either 4, 8, or 12 via the differential outputs).   Thus, it's not really "8" anymore.   For my use case though, it's still 8. 

[AAH]

Looks good Dan. Looking forward to seeing what it looks like populated.

[dkulp]

IT'S ALIVE!!!


I managed to get it mostly assembled (forgot to order some quad differential chips and only had two sitting here) but it's certainly in a testable state.   The BBB powers up, there seems to be enough power for the WIFI and such.   All 8 local channels work perfectly.   The 4 DMX outs on the middle RJ45 work perfectly.   I'm waiting for a Diff.Receiver board to arrive so I cannot test that functionality at all yet and without the quad/diff chip, I cannot test the other set of 4 DMX's, but things certainly are looking fairly good so far. 

[dkulp]

So I finally got to test the differential receiver parts of this.   The good news is everything is wired perfectly and I can set it to 20 outputs and get pixel data out on all three of the differential ports.   Thus, it seems to all be working from a hardware side.


The bad news is changing from DMX/PixelNet to pixels requires a complete reboot right now, not just a restart of FPP.   It seems like the FPP restart doesn't call any routines to shutdown outputs so the DMX PRU code continues to run on the second PRU and interferes with the pixel code on the first PRU.  I need to figure that out.   I think at fpp startup, even if DMX isn't configured, I need to clear the data and send the "stop" command to the second PRU just in case it's running.   Not really sure yet.  Something I'm looking into.


In any case, from a hardware standpoint, things are looking very good.   

[CaptainMurdoch]

The bad news is changing from DMX/PixelNet to pixels requires a complete reboot right now, not just a restart of FPP.   It seems like the FPP restart doesn't call any routines to shutdown outputs so the DMX PRU code continues to run on the second PRU and interferes with the pixel code on the first PRU.  I need to figure that out.   I think at fpp startup, even if DMX isn't configured, I need to clear the data and send the "stop" command to the second PRU just in case it's running.   Not really sure yet.  Something I'm looking into.

Can you try stopping fppd via "fpp -q" instead of using the button in the UI or the fppd_stop script?  "fppd -q" should do a graceful shutdown allowing the Channel Output Close() methods to run which should shutdown LEDScape which should stop the code running on the PRU.  The -q option to fpp was something I added, but didn't get around to updating the stop script to try a graceful shutdown before killing the fppd process.

[dkulp]

Can you try stopping fppd via "fpp -q" instead of using the button in the UI or the fppd_stop script?  "fppd -q" should do a graceful shutdown allowing the Channel Output Close() methods to run which should shutdown LEDScape which should stop the code running on the PRU.  The -q option to fpp was something I added, but didn't get around to updating the stop script to try a graceful shutdown before killing the fppd process.

It's pretty close, but there were a few other issues.  Shutting down the BBB48String completely shuts down the prusdrv and unmaps the memory so by the time we get to shutdown the BBBSerial, that fails.   Also, the LEDScape code only looks for events from PRU0 so it never knows when the pru1 code is complete.    I just committed some changes to my branch that fixes a bunch of this.   Some of it probably isn't ideal as I added some sleeps in various places to hopefully allow fppd to have enough time to cleanly shutdown.   

[dkulp]

Since the BBB has all kind of extra IO pins, I decided to try and squeeze an expansion connector for the F16v3 expansion board.   I'm not convinced there is enough clearance between the IC's yet (need to find out what the minimum is), but if it fits, that's another way to get some more outputs.   

[CaptainMurdoch]

Since the BBB has all kind of extra IO pins, I decided to try and squeeze an expansion connector for the F16v3 expansion board.   I'm not convinced there is enough clearance between the IC's yet (need to find out what the minimum is), but if it fits, that's another way to get some more outputs.   

Nice.  David and I have talked in the past about being able to share the expansion boards in the past, so I think this is a good option to have.  One of the Pi libraries I have looked at can directly drive up to 16 outputs of WS2801 or APA102 pixels on a single Pi.  Once I have time to get that library integrated with FPP, it could be another use for a Pi->F16v3-expansion adapter board.

[dkulp]

I've created an interest thread:

http://falconchristmas.com/forum/index.php/topic,7318.0.html


to see if it's worth running a group buy.