BeagleBone AI
I'm surprised no one has brought this up yet:
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.
- https://beagleboard.org/ai
- https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual
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
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).
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).
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...
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).
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.
Comments welcome.
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)
Right now the user control panel and admin page display the cpu temperature and core frequency (the BBG/B doesn't have temp monitoring).
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?
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.
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.
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.
This is just a progress report. There is a long list of work to do.
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).
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)..
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.
Is it possible to run the Kiwi+BBAI passively cooled?
12 kiwirecorder sessions would be connecting to the kiwi, no waterfall.
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.
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!
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.
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
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
Other commands are: