You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've put CircuitPython on a PyGamer. My understanding is the audioio libraries nowadays put the output at the midpoint 32768 (3.3V/2 =1.65V) by default.
As the third command runs both outputs jump to around 1.65V as expected. They then drift slowly (perhaps 5 seconds) to A0=0.03V and A1=2.46V (multimeter and oscilloscope show same thing). That drift is almost linear but there is a slight jump towards end.
A0 and A1 in isolation behave similarly although maybe exact, final resting values differ a little:
import board, audioio
dacs = audioio.AudioOut(board.A0) # just DAC0
import board, audioio
dacs = audioio.AudioOut(board.A1) # just DAC1
These two independent versions have similar output
PyGamer does have some hardware attached to A0/A1. I have the speaker attached but that's other side of amplifier which I am not enabling. I have nothing in the 3.5mm socket.
There's mention of a refresh setting somewhere. It sounds like that's needed when you want the output to hold and are not outputting samples constantly at a reasonable rate. I think @dhalbert may have set this to 2 in #649 - I wonder if that's used for bothanalogio and audioio? The latter might be expected to write constant values but given that wavs/etc are not always played then there will be no activity phases where it would be expected to hold midpoint value (the value can be customised with quiescent_value).
To my surprise Feather M4 (mine's running 4.0.1) does same thing and that has nothing connected to A0/A1 AFAIK so rules out any significant effect from external components. I tested analogio.AnalogOut too on Feather. That drifts slowly from ~ 0V to ~ 2.2V (then jumps further to 3.3V if oscilloscope probe is briefly removed) when initialised but as soon as a value is assigned it holds that output voltage.
The text was updated successfully, but these errors were encountered:
kevinjwalters
changed the title
audioio initialisation has strange DAC outputs on PyGamer (SAMD51)
audioio initialisation has strange DAC outputs on at least two SAMD51 boards
Jul 12, 2019
I've put CircuitPython on a PyGamer. My understanding is the
audioio
libraries nowadays put the output at the midpoint 32768 (3.3V/2 =1.65V) by default.From REPL on
4.1.0-beta.1
I'm runningAs the third command runs both outputs jump to around 1.65V as expected. They then drift slowly (perhaps 5 seconds) to A0=0.03V and A1=2.46V (multimeter and oscilloscope show same thing). That drift is almost linear but there is a slight jump towards end.
A0 and A1 in isolation behave similarly although maybe exact, final resting values differ a little:
These two independent versions have similar output
PyGamer does have some hardware attached to A0/A1. I have the speaker attached but that's other side of amplifier which I am not enabling. I have nothing in the 3.5mm socket.
Other on-going SAMD51/M4 DAC related discussions:
There's mention of a refresh setting somewhere. It sounds like that's needed when you want the output to hold and are not outputting samples constantly at a reasonable rate. I think @dhalbert may have set this to 2 in #649 - I wonder if that's used for both
analogio
andaudioio
? The latter might be expected to write constant values but given that wavs/etc are not always played then there will be no activity phases where it would be expected to hold midpoint value (the value can be customised withquiescent_value
).To my surprise Feather M4 (mine's running
4.0.1
) does same thing and that has nothing connected to A0/A1 AFAIK so rules out any significant effect from external components. I testedanalogio.AnalogOut
too on Feather. That drifts slowly from ~ 0V to ~ 2.2V (then jumps further to 3.3V if oscilloscope probe is briefly removed) when initialised but as soon as a value is assigned it holds that output voltage.The text was updated successfully, but these errors were encountered: