• Interactivity

  • BBG WiFi support??[WAS: Noisy analog inputs with Pd]

Are the analog inputs 0-7 DC coupled?

I did - the c++ example does the same thing.

Can you confirm the pot is pushed down firmly on the breadboard? Also, can you test by connecting the 3.3V line from P9_03 straight to the analog input ?

Yeah, I've done both of those. The values right from the 3v3 supply do the same thing. And that supply is pretty stable when I test it on my hardware scope.

Hi,

I just traded out the BB Green for a BB Black and everything seems fine. No more noise.

Unfortunately, I'm using the Belas for a summer class I'm teaching and we just bought 10 BB Greens. Oops.

If you might happen to know of a workaround for the Green, that would be awesome....

Anyway, thanks for the assistance. I'll keep you posted as to any more Green/Black issues I might run into.

Cheers,
Colin

Hi Colin,

Strange problem. We'll look into what's going on with the BBG -- it should be the same in every practical respect so hopefully there's a simple workaround. Something you might check in the meantime, since you have a hardware scope, is the quality of the analog outputs (use one of the demos which generates a signal on them). If that looks okay then the problem is specifically in the ADC, otherwise it might have something to do with the SPI bus that drives both the converters.

Also, when you mention you tried this with two Belas, did you also try with two different BeagleBone Green?

Yeah, I tried with two different Greens and at least a few Belas.

alright thanks, I will test the BBG we have tomorrow.

I have no troubles with the BBGs we have here. These are 1-year old now, we bought them as soon as it first came out. Manufactured by Seeed, serial numbers BBG 115080763, BBG 115081013.
Is it a regular BBG or the BBG wi-fi you are using?

How are you powering yours? I am powering mine from my MacBook via usb.
If you are powering from a laptop via USB, do you observe the same behaviour when powering from different laptop and with/without it being connected to the power adapter?

    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....

      I just looked up the BBG Wireless schematic:

      https://github.com/Seeed-Studio/beaglebone-getting-started/blob/BBGW/Docs/Hardware/BeagleBone_Green_Wireless_V1.0_SCH%26PCB/BeagleBone_Green_Wireless_V1.0_SCH.pdf

      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.

        Have you tried

        cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins

        to 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".