Huh. Both of the BBG's I tried did exactly the same thing. But yes, I'm using the wireless ones. I'm powering mine from my laptop - Toshiba Satellite. I can try powering from my Mac, but don't see why that would make a difference. I'll try that, though, as well as powering from an adapter. I'll let you know....
BBG WiFi support??[WAS: Noisy analog inputs with Pd]
I just looked up the BBG Wireless schematic:
It adds a WiFi and Bluetooth module which uses a number of signals which appear on the expansion header, and which were not used by previous generations of the board. As far as I can tell, this is not well documented, but compare p. 9 to p. 10 to see which pins are in use.
In particular, it uses the same four McASP (audio) pins that the Bela cape uses, as well as some of the GPIO pins on P8. The ADC problem you see would seem to come from the SPI0 pins, not McASP, and those pins aren't affected as far as I can tell. So this is only a partial explanation.
Still, for any of these high-speed traces, extra load on the board could create signal quality problems, with unpredictable results.
As it happens, the BBG Wireless uses GPIO1_29 as the OE (output enable) signal for the level shifters which drive the WiFi/BT module. That's Pin 26 on P8, previously unused by the BBB and BBG. It's also the same signal we use for speaker amplifier muting on the Bela cape. So unmuting the amps also means enabling all those bidirectional level shifters.
A quick and dirty test would be to run your program with the -M command line argument (mute speakers), which should keep those level shifters turned off. Have a look/listen to all three major converters -- audio, analog in, analog out -- to see if there is any change in result on them.
From there, a more detailed investigation would involve checking the signal quality on the high-speed traces on a scope. I will also see if I can get myself a BBG Wireless for testing.
Hi Andrew and Guiliomoro,
Again, thanks for all the help with this. I tried running everything with my Mac - same problem. There is unfortunately no way to power the BBG Wireless without usb connection - no 5v jack.
Andrew - is there a way to run Pd with command line arguments from the IDE, or do I need to run it from the console? Also, do you have a list of other command line arguments for Pd/Bela anywhere?
Cheers
Sorry it's been a minute since my last response - have just been ridiculously busy. Anyway, muting the speakers doesn't seem to help at all. I just started looking for a way to disable the wireless system, but haven't found anything yet. Have you guys been able to get one?
Yeah we are also pretty booked up right now. We haven't gotten a BBGW yet but will try to do this in the next couple weeks. In the meantime, can you try some of my other suggestions for testing?
For example, can you check if the analog outputs have the same kind of noise (and in fact if they work at all)? Can you compare the SPI signals on a scope between the BBB and BBGW? You can find a schematic of the cape here (use EAGLE to view): https://github.com/BelaPlatform/bela-hardware/tree/master/cape/bela_cape_rev_B1
The relevant pins are on P9: 15 (ADC chip select), 17 (DAC chip select), 18 (data out), 21 (data in), 22 (clock).
a month later
I finally got a BBGW to do some testing. The results aren't what I expected:
First of all, the analog outputs work fine for me. Output is fine, SPI lines are fine.
On my board, the analog input doesn't work at all. No sign of life on the SPI_MISO pin (which stays high), and more unexpectedly, no sign of life on P9_15 which is the chip select line for the ADC. The latter would explain the former.
Digging further, I find that this pin (GPIO1_16) has been set to pinmux mode 0 on the BBGW, but the exact same image running on the BBB sets it to mode 7. Mode 7 (GPIO) is correct; mode 0 is the gpmc_a0 signal. The neighbouring pins which also have GPMC functions are unaffected.
There are two other pins (pin 34 and pin 88, using the pinmux numbering) which also change from the BBB to the BBGW, but neither of these pins appears to go out to P8 or P9, so I don't know what they are doing. More to the point, I'm not yet sure where in the code it would be detecting this different hardware and setting the pins accordingly.
I don't see anything on the schematic of the BBGW that indicates why P9_15 would be used by anything else, so it's a bit of a mystery.
- Edited
Have you tried
cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinsto check what the actual muxer value is for that pin - if that helps?
Yes, that's where I found it out to begin with. On BBB:
pin 16 (44e10840) 00000027 pinctrl-single On BBGW:
pin 16 (44e10840) 00000008 pinctrl-single And yet, in the pinmux-pins file, it still shows as "unclaimed".
giuliomoro changed the title to BBG WiFi support??[WAS: Noisy analog inputs with Pd] .
a month later
Hi czyskows, andrew, giuliomoro
were you able to connect to wifi/bluetooth using the Linux bela 3.8.13xenomai-bone41 image? It seems there are no drivers for the WiLink 8 (L18xxMOD) Single-Band Combo Module – Wi-Fi, Bluetooth, and BLE
eth0 Link encap:Ethernet HWaddr ---------------------
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 
TX bytes:0 (0.0
Interrupt:40
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 TX bytes:0 (0.0
usb0 Link encap:Ethernet HWaddr -----------------------
inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252
inet6 addr: fe80::f054:2eff:fec5:7e4a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6980 errors:0 dropped:0 overruns:0 frame:0
TX packets:6855 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:460749 (449.9 Ki TX bytes:3801968 (3.6 Mi
I see that there are drivers available for Linux here http://www.ti.com/tool/wilink-sw. Is there any walkthrough on how to install?
Would it be easy to integrate on the Bela image? It appears that the new BeagleBone Black Wireless also has the same module, it would be interesting to incorporate this.
Thanks,
Francisco
it would be in principle possible to install those drivers, but we'd need to make sure there is no pin conflict between the BBGW and Bela, which is what seems to be happening just now.
6 days later
Quick update: we got the analog in to work with a device-tree overlay, but they work as bad as they worked out-of-the box for czyskows 
.
The driver for the wifi module seems to be on the board already, but there is no way to test it at the moment because the device is not properly configured in the device tree. The default BBGW device tree does not boot with this kernel (I think it requires a kernel > 4.1)
My knowledge of dtos is limited, so I spent quite some time trying to see if I could adapt the device tree to properly recognize the device, but I am not quite there yet and I do not think I am going to go back to it any time soon UNLESS we get the analog inputs to work properly, at which point the effort would be justified.
I pin here a couple of references for anyone wiling to keep trying ...
http://processors.wiki.ti.com/index.php/WL18xx_Platform_Integration_Guide#Board_Device_Tree
https://community.nxp.com/thread/358671
The alternative would be to get the default device tree of the BBGW and try to back-port the diffs between that and the default BBG one into our device tree (ignoring all the phandle changes at the beginning, I'd assume).