The forum is read-only currently.

BeagleBone AI

I'm surprised no one has brought this up yet: Not available until later this year, and supposedly +/- USD $100. Note integrated WiFi and dual core processor (with mandatory heatsink).
The schematic was published a few days ago https://github.com/beagleboard/beaglebone-ai/blob/master/BeagleBone-AI_sch.pdf
and I'm starting to look at Kiwi compatibility issues.

Can you electronics experts do me a favor and look at the issue I opened with them please? https://github.com/beagleboard/beaglebone-ai/issues/10
I am not an expert and would like to know if I'm wrong about this or not.

Comments

  • Good area to question - I found powering the BBBW I had to use the port on the BeagleBone itself and even then it was fussy about DC leads.
    I did consider trying to power that through both ports but figured that was fraught with loop problems and negates DC filtering anyway.
    Stick a couple of fast diodes in there and we might not need an antenna (/sarcasm).
  • jksjks
    edited September 2019
    In reviewing the PMIC design (again) for the BBB/BBG I found I was able to run the Kiwi with as little as 4.3V at the 5VE header pin, which is essentially the same as the DC barrel jack on the BBB. This surprised me. I thought the PMIC enforced a much higher minimum. But the spec for the PMIC "AC source" input is, in fact, 4.3 - 5.8V.

    As long as I used my good power supply that could meet the 50 mS ramp up time and didn't brownout below 4.3V during the ramp (due to power supply cable voltage drop from inrush current) then I could power-up and run every time. These of course are the two most common power supply problems people experience. With the much higher current draw of the AI this will be even more of an issue when using it together with a Kiwi board. This assumes the Kiwi will even work with an AI which is still an open question (I have no idea when I might get my hands on one).
  • edited September 2019
    I have found the barrel connector to be a weak link, I purchased some "quality" leads from Ebay and the lead was indeed multple strand, decent copper and very flexible, but inside the connector moulding they had not made a good solder joint on all of them. The issue only came to light in this use.
    I've gone over to XT30 connectors where I can, simple lightweight two pole that will take 30A surge, I was going to swap the power connector on the cape to one but they don't seem to do many PCB mount ones and the self shorting of the barrel plug has been of some use to me if the rare bad PSU lock up condition (quicker reset).

    Even if the Beagle board will survive 4.3V, the diodes (from a quick glance at random spec and your simulation) will drop ~1V at 2A so unless there are no caps on the AI board (joke) it can't reliably work from cold unless there is some other condition met like a chance current limit (that just happens to satisfy the BeagleBone's voltage curve) or higher initial voltage supply.
    I can't help feeling we will be discussing the new USB-C external power filter and 5.3Vsupply in the coming months.

    BTW the irony of my Nickname responding to this sort of thread is not lost on me, but hey at least I'm trying...
  • jksjks
    edited September 2019
    AI available as of today. USD $125 from Mouser (ugh, was hoping for closer to $100).
    https://beagleboard.org/ai
    https://www.mouser.com/ProductDetail/BeagleBoard/BBONE-AI?qs=/ha2pyFaduhdfTYrXET7yN9wnaGE0qxwEhEzGiy6MRnZ/3CLosDLNg==

    The Github site already indicates there will be an A2 version to fix some bugs. Hopefully including the one I pointed out (which they don't fully appreciate yet).
  • edited September 2019
    It's nice to know the platform is still growing while retaining the pinout.
    Over here it is listed at £114 currently, someone has to test the RF profile but I can just about fend off the buy button for now.
    Mind you if the hams with big gardens start reporting it works well I'll be tempted to upgrade one Kiwi to discover what difference it makes.
  • jksjks
    edited September 2019
    It's not Kiwi software compatible (yet) -- not even close. So no one should be buying one (yet) with that expectation. It may not even be hardware compatible depending on the powering issue that is still TBD.
  • I added a comment with a diagram of the AI powering issues I'm concerned about: https://github.com/beagleboard/beaglebone-ai/issues/10
    Comments welcome.
  • jksjks
    edited October 2019
    The Kiwi is starting to function using a BBAI in place of the BBG/BBB. Lots of issues still, but in principle it works.

    Turns out the US $125 price from Mouser and others is $100 MSRP plus the current $25 US China tariff. So for example you can get it from UK Farnell for £80/$100 (but then +VAT if delivered in EU). Seeed's Shenzhen-based website sells it for $125 which I find both amusing and sad. The AI is built by Embest, a, you guessed it, Shenzhen company. Go figure.

    The thing is a beast. If you don't use some significant forced-air cooling it goes into thermal shutdown pretty quickly. It will also shutdown when your power supply can't deliver enough current! (5V 3A max)

    Compile times for Kiwi codebase: (clang compiler, "make -j n" used)
    BBAI    Debian 9.11    1m50s (3x faster)    TI AM5729 ARM Cortex-A15, 2 cores, 1.5 GHz
    BBB/G   Debian 8.5     6m10s                TI AM3359 ARM Cortex-A8,  1 core,  1.0 GHz
    
    PowernumptyWA2ZKDLX1DQ
  • Heatpipe to the metal case?
  • Think about the difficulty in implementing that in the context of the metal case assembly. Plus conduction/convection cooling is always uncertain. A fan does wonders. Also, it's more than just the cpu (which comes with a small heatsink attached). The PMIC almost runs hotter than the cpu does. It also doesn't help that the Kiwi is sitting on top. You need to move air through the case and dump the heat buildup.

    Right now the user control panel and admin page display the cpu temperature and core frequency (the BBG/B doesn't have temp monitoring).
  • edited October 2019
    So if they sold the AI and Kiwi cape without soldered sockets adventurous types could reverse them so that the AI sat on top, maybe even put a shield between.
    I know it would mess with lots of mechanical stuff but I'd love to try it. Would not even need full length sockets.

    The modular design of the Kiwi does offer more potential, about time it was better recognised for what that could offer.

    So who is going to ask about potential performance? all HF WSPR slots on one Kiwi?
  • Moving a little air makes perfect sense because it automagically seeks out all the available paths through the obstructions created by the two board sandwich and the irregular geometry of the components they contain. Being inside an enclosure is actually an advantage because you can create a pressure differential more easily versus open air and get away with a smaller fan.

    The little fan I have stopped because a wire fell onto the blades. I was wearing headphones and didn't hear that it had stopped. The temp went from 45 to 75 degC and the software dropped the cpu clock from 1.5 GHz to 500 MHz just like it's supposed to. I was wondering why my complies had slowed down. It recovered in just a few moments after the fan was back on.

    It's too early to ask about performance. One of the issues I'm working on is the fact that the custom thread package the Kiwi software uses to meet the realtime requirements assumes a single core environment. You have to interact with Linux to be able to use the second core. Something that is fraught with peril (from a realtime predictability standpoint). The Kiwi software stays as far away from Linux as possible.
  • jksjks
    edited October 2019
    Below shows progress with an experiment to get a 14-channel configuration working using a BeagleBone AI. The challenge is to move as much processing to the second cpu core of the AI as possible so as not to impact the realtime requirements of serving the 14 audio channels (plus the usual 12-channel GPS etc.) It seems to work. A 14 audio DDC + 1 waterfall DDC configuration (rx14_wf1) was made to fit in the FPGA (LUTs now 97% full) by reducing the amount of CIC filtering logic slightly.

    Note below that the processor temperature and clock speed are displayed. The cores are currently running at rate automatically adjusted based on temperature between 1.0 - 1.5 GHz due to the reduced cooling configuration I'm testing.

    image

    The Kiwi's internal WSPR extension is running on all 14 channels as a worst-case test since WSPR decoding is so cpu intensive. The fact that this works does not change the fact that Rob's wsprdaemon is the superior solution for anything but casual WSPR monitoring. In fact 14 channels was chosen in support of getting a single Kiwi to work in an all-band wsprdaemon setup.

    Below is output from the Linux "ht" command. It shows how certain components of the software have been moved to new Linux processes separate from the main Kiwi process and "locked" to the second core of the processor. "kiwid" is the main process and is locked to cpu0 as seen in the "cpu" column. The other "kiwi.xxx" processes are locked to cpu1. Of interest here is the "kiwi.wsp" process which runs the collective WSPR decoding of all 14 channels.

    image

    This is just a progress report. There is a long list of work to do.
    PowernumptyChrisSmolinskiWA2ZKDHB9TMCKA7UG0LUJrz3dvpWA2TP
  • Awesome.
    I know it is not the goal but what a trick - all band WSPR in one box.
    Also a fine way to upgrade the capabilities of the SDR, both computing power and Linux distro, for those who could use more channels and have the budget (power and beer tokens).
  • Wow, this is indeed very impressive.
  • jksjks
    edited October 2019
    Updating the Debian release (e.g. 8 to 9 or 10) on existing Kiwis needs more research. There are conflicting reports on the net of how successful it is to upgrade Debian releases without reinstalling. It has to be 100% reliable if it is going to be part of the standard Kiwi software update process. Otherwise it will require a reinstall which many customers will find painful/annoying. And which will also cause a big support burden on us when the reinstall fails for whatever reason.
  • I'll keep watching your progress. I've got a fairly popular KiwiSDR due to my low noise levels (I live in a rural area and have room for large antennas), so being able to offer more channels to users would be great, as during peak listening times it's often full. Thanks for looking into this.
  • jksjks
    edited October 2019
    It's too early to be certain, but some of the changes being developed for the AI might offer advantages to existing Kiwis using BBB/Gs. Example: Using a separate process to handle the stall caused by the synchronous-I/O-only SPI interface gives some cpu cycles back to other Kiwi tasks. Like doing more waterfall FFTs or whatever (this is the "kiwi.spi" process seen in the ht command in the prior post).

    I also have a new idea to reduce the number of FPGA memory blocks (BRAMs) required to hold all the waterfall CIC output -- the dominant consumer of BRAMs by far. It requires two smaller buffers in a ping-pong configuration and a very carefully crafted bin packing algorithm to place waterfall samples in the buffers at precisely the right time. The Kiwi design document talks about why this is such a tricky issue (the "acquisition time problem") and explains why such a brute-force solution is currently used.

    For example the rx4_wf4_12k config is currently using 100% of the BRAMs. rx8_wf2_12k only uses 80% but is limited by BBB/G cpu cycles. Same for 3rx_3wf_20k. Getting waterfall BRAMs freed up could possibly allow the number of channels to increase, assuming enough Beagle cpu cycles can be found.

    The whole Kiwi design process is very much reminiscent of Whac-a-Mole. Good thing we kept the hardware so flexible (programmable)..
    PowernumptyWA2ZKDLX1DQHB9TMCKA7U
  • edited October 2019
    Should you require any remote beta testers..
    I'm not saying I bought one, but I bought one.
    Just to get familiar you understand, not in expectation of being able to run it as a Kiwi any time soon.
    I'm just looking at how to put it into some spare box with a decent fan, In best local dialect "they bugger do get 'ot mind".
    The heatsink is below the BGA FPGA and I dislike heat cycling those things too much.

    I'm also trying to work out if the PI 4 or Stontronics USB-C supplies are just two conductors so I can use my preferred XT-30 connectors in-line to be able swap plugs, add ferrite and extend leads.

    Doh just opened Stontronics box, looks like just two. I did wonder if they were using any kind of signal or sense wiring on the USB-C I assume not.
  • Hi,
    Is it possible to run the Kiwi+BBAI passively cooled?
    12 kiwirecorder sessions would be connecting to the kiwi, no waterfall.
  • The only way IMHO is to have a large passive heatsink.
    The copper laptop cooler I used, if left with the fan off, idles at about 60C on a cool room.
    I only found this by accidentally knocking the fan supply and spotting the elevated temperature later.

    The BeagelBone supplied heatsink is designed for use with a fan, it is not suitable for use without.
    HB9TMC
  • I decided to bite the bullet, and I've finally ordered myself a Beaglebone AI, due to arrive Monday or Tuesday next week.

    I've been wishing I had more audio channels, and more processing power. I run 6 or 7 WSPR listeners from an RPi4 on both of my Kiwis, so I have no headroom for playing with the DRM decoding. I've also run into issues with 2.4GHz wifi starting to fail for me for some reason, and 5GHz should be a lot more stable.

    I've got a few fans in the order as well, and I'll be building some ducting to make sure the CPU stays cold enough to be useful.

    In an ideal world, I'd like if it were possible to have 6-8 WSPR listener audio streams without waterfall and two or three normal audio with waterfall streams that were DRM and TDoA capable. I also know it'll be a while before that becomes a possibility! :)
  • That last "6-8 WSPR + 2 normal" strikes me as a good move, I have shut my IA down so I can get back to thinking about heatsink options.
    New Xmas electrical items at neighbours knocked my (14CH) WSPR results badly so it's good time to work on hardware.
    I've got one of the proper Kiwi cases now so will look at using the shell as part of a passive setup (if only to cover fan failure).
    I also want to try moving the BeagelBone right down to the base (or other ground-potential plate), I found that helped with Ethernet spurs on the green.

    The AI has lots to offer, if they launched a number of extra cooling options focused on cape use it would really open up.
    Forced cooling works fine but some decent engineering (not from me) should be able to cover more uses and allow silent operation.
  • Any possibility of offering more than 4 full receivers with a a Beaglebone AI? 7 or 8 for example?
  • @Chris: No, 4 full receivers (i.e. rx4wf4) completely fills the FPGA. Beagle cpu cycles are not the bottleneck in that case.
  • I am managing heat with this duct tape setup. It will hit a high of 52C with 2 DRM slices running with 2 AM slices. Typically runs 47C with all 4 AM slices. Running 1GHz. I think if this little 5v fan which is running on 4.4v from the USB jack, was replaced with a 12v fan or small shop vac, then it would probably run all 15 slices for WSPR at 1.5GHz, maybe.







    Ron
    KA7U





  • Obviously I omitted the old AMD cooler on the outside and the heatpipe is actually stuck with thermal adhesive now.
    The case opening is also a slot now.

    Idles at at about 52C with fan off
    DRMx2 42-43C with fan (12V fan at about 7V)

    Work in progress.
    Stu
  • ^ that's a nice clean cooling setup.

    My BBAI arrived, I was able to do the OS updates and kiwi build in the office before doing the swap when I got home. For cooling, I have two 40x40x20mm 5v Delta fans, each pushing 5.5 CFM. I had them ducting through the Seeed enclosure with the ends removed, but that resulted in temps of 57 degrees. I removed the top of the enclosure and pointed the fans at the BBAI, and I'm sitting comfortably at 1GHz speed, 44-47 degrees with two DRM streams decoding, and 6 WSPR streams going to a Pi4. I'm using the onboard wifi, though I have found it a little flakey - I'll see how it behaves for the day.

    Overall, I'm reasonably impressed. I wanted to be up to date on the OS side of things and I can more easily do that with BBAI than BBB and still have kiwid function as expected, and I wanted to be able to use DRM decoding without affecting the WSPR streaming. The other major benefit to me has been the ability to use 5GHz wifi, I had not been able to locate a USB adapter that worked with the BBB kernel that was on 5Ghz channels, and now I can remove the ethernet to wifi bridge that had been causing problems. I don't have the capability of getting an ethernet cable to the Kiwi in the place I'm staying.

    It is a pity that the BBAI runs so hot, and it's a pity that the minimum speed is 1Ghz. It would be quite useful to have lower clocking states than the current 1Ghz min , but that's beyond the scope of our group. Maybe for V2 of the BBAI.

    John - if you ever want to test something for BBAI Kiwi, please let me know, I'd be glad to help out.

    -Cathal
  • Well, you can force the AI to run at 500 MHz. But the Kiwi server may have problems at that clock rate. From a shell window (via ssh/PuTTY connection or admin console tab) use the command "cf5". Then "cf" to check that it actually switched. Remember that the BBB/BBG runs at 1 GHz (fixed).

    Other commands are:
    cf15 = 1.5 GHz
    cf11 = 1.176 GHz
    cf1  = 1 GHz
    
    cathalferris
Sign In or Register to comment.