Rev 7 Seed Is Detected As Rev 4

Hi,
I am having an annoying hiss noise on the output (I am not blaming the DS module, it could be the Terrarium board instead) so I started experimenting trying to eliminate this hiss.
One thing I found was that the board was detected as been Rev4, while it should be Rev7 as the codec in my board is the PCM3060
According to the latest datasheet, Rev4 has no pins tied to ground for auto-detection purposes, Rev5 has PD3 pin and Rev7 has PD5 pin. But in daisy_seed.cpp there is a check for PD3 and PD4, as shown below

DaisySeed::BoardVersion DaisySeed::CheckBoardVersion()
{

  • /** Version Checks:*

  • *  * Fall through is Daisy Seed v1 (aka Daisy Seed rev4)*
    
  • *  * PD3 tied to gnd is Daisy Seed v1.1 (aka Daisy Seed rev5)*
    
  • *  * PD4 tied to gnd reserved for future hardware*
    
  • */*
    
  • /** Initialize GPIO /

  • GPIO s2dfm_gpio, seed_1_1_gpio;*

  • Pin seed_1_1_pin(PORTD, 3);*

  • Pin s2dfm_pin(PORTD, 4);*

  • seed_1_1_gpio.Init(seed_1_1_pin, GPIO::Mode::INPUT, GPIO::Pull::PULLUP);*

  • s2dfm_gpio.Init(s2dfm_pin, GPIO::Mode::INPUT, GPIO::Pull::PULLUP);*

  • /** Perform Check /

  • if(!seed_1_1_gpio.Read())*

  •    return BoardVersion::DAISY_SEED_1_1;*
    
  • else if(!s2dfm_gpio.Read())*

  •    return BoardVersion::DAISY_SEED_2_DFM;*
    
  • else*

  •    return BoardVersion::DAISY_SEED;*
    

}

The module is always detected as DAISY_SEED, this causes it to initialize the codec as AK4556 instead of PCM3060
I have changed the code to test PD5 instead of PD4 but it reads as “1”, so something is wrong here: the documentation, the module or my undertanding of the auto-detection process
Thank you in advance for your response

Hello
From here (p12) :

Notes:

  • Rev5/Rev7 do not use I2C pins. Auto-software detects hardware as Rev 4 Daisy in libDaisy, so it can remain
    backwards compatible with existing firmware. See table below for which pin each rev uses for its version check.

I hope this answer your question

Hello Axel, thanks for your answer,

The version pin is very well explained in the datasheet, the problem is that on my module, witch is Rev7, the pins PD5 and PD3 (and also PD4) are read as “1”, so the module is incorrectly detected as Rev4. Perhaps I have received a defective unit…?
The CheckBoardVersion() function in daisy_seed.cpp seems to be wrong, as it checks PD4 instead of PD5, but this is something that I can fix myself.

BR
JRSM

I meant

  • the method CheckBoardVersion is never called in the lib init methods (except it seems for the daisy patch, not the seed itself) EDIT : it is indeed called, see later posts.
  • the MCU do not communicate with the codec via i2c nor any other protocol
  • the codec is configured in an hardware way, via pins, so there is no way to change the configuration via software

The module is always detected as DAISY_SEED, this causes it to initialize the codec as AK4556 instead of PCM3060

There is no difference between those versions in the way the software acts. The codec is not initialised (by that I mean configured) by software. EDIT : there are difference regarding pinout and reset pin but no actual register configuration

To me it is expected that the rev7 hardware is detected as rev4, as explained by this sentence.

Rev5/Rev7 do not use I2C pins. Auto-software detects hardware as Rev 4 Daisy in libDaisy,

I’ll let someone from electro smith confirm or correct me, but that’s what I understood from the spec and the code.

Worth to see this threads :

I think this line is incorrect, and should read:
Rev4/Rev7 do not use I2C to configure codec. Software auto-detects Rev7 hardware as Rev4 in libDaisy.

Documentation is important, and words are important in technical documentation. The quality of Daisy documentation isn’t going in the right direction.

Accurate schematics can reduce confusion, but intentionally obfuscated schematics increase the likelihood of error, and increase the need for correct text documentation.

1 Like

Hi, tele_player
I totally agree, documentation has to be accurate and not interpretable.
There is still the question of how to detect the revision of the board. The datasheet says that Rev7 has the PD5 pin connected to ground, but this is not true on my board.

I think that might just be an error, but only the real schematic can answer that.

But it doesn’t really matter for your noise problem. Ak4556::Init() only toggles the codec reset pin.

This issue of card version detection is of minor importance, as it doesn’t matter whether the revision is Rev4 or Rev7 because the codec cannot be configured over I2C, which is a real shame because it is a feature that would not have added cost.
Anyway, the CheckBoardVersion() method does get called during initialisation, this is done from hw.Init() which calls ConfigureAudio() which calls CheckBoardVersion(). All of Electro-Smith’s examples for the Daisy Seed do this, even the simplest “bypass”. I’ve debugged the code and here you can see the calls.

A clarification from Electro-Smith would be welcome.

Regarding the noise, which is really the issue that worries me, I am trying to find out if it is produced by the codec or by a poor layout of the Daisy Seed or Terrarium PCB. At the moment what I can say, after running the program step by step, is that my setup is absolutely silent until the exact moment when the SAI (Serial Audio Interface) is initialised and the DMA starts transferring data between the codec and the CPU. At that precise moment a noise begins that I wouldn’t know how to define, it’s a mixture of white noise with some variations and whistles of different frequencies. I have to do more tests, but for the moment everything points to the data interface signals messing up the output signal, and that’s something that originates in the Daisy Seed card…
I’ve seen on the forum how some people have applied gain on the input and attenuation on the output to reduce the noise level, but I think that’s just patching the problem rather than solving it.

What is your callback doing? Is it doing pass through, or are you writing 0.f ? And what level is the noise, relative to, for instance, a full code sine wave?

Yes that’s what I was trying to express from my first post, sorry english is not my native langage and I may have struggled to get the point across.

My bad ! I edited my answer to correct that mistake. I went to quick through the code.

The callback writes 0.0f to the output. It is extremely difficult to analyse the noise because it is quite low and gets lost in the background noise of my oscilloscope (Siglent 1202X-E).
I tried using the FFT function to find out its composition, and there seems to be a tone around 1,9 kHz regardless of the block size, but it is so low that it is not certain. I used a trick to guess the noise level, I generated a 440 Hz tone and adjusted its amplitude until it seemed to have an audible level similar to the noise. The level was around -75 dBV (0,2 mV RMS). As a comparison, the output level of a strat guitar is in the order of 200 mV (-14 dBV), which leaves a S/N ratio of 60 dB. You might think that this noise is negligible, and not too bad for a live performance, but it is not acceptable for studio quality.
The next step will be to modify the Terrarium board to have an output gain of 32 (30 dB) to be well above the noise floor of the oscilloscope for accurate measurements.
There is room to apply a gain of say 2,5 to the guitar input and the same attenuation to the output, which would give us 9 dB of gain in the S/N ratio, but that would leave us no room to use the pedal with humbuckers, active pickups or effect loops.
Another area of work will be to place low-pass filters at the input and output of the Daisy Seed for better attenuation of residual noise. The input one may be superfluous, but it costs next to nothing to ensure that there are no unwanted signals causing aliasing, while the output one is recommended in the PCM3060 datasheet (https://www.ti.com/lit/ds/symlink/pcm3060.pdf p.23):

“This filter is not enough to attenuate the out-of-band noise to an acceptable level for many applications in general. An external low-pass filter is used if further out-of-band noise rejection in required.”

I think the Terrarium board has been designed for audio frequencies but is not suitable for digital applications, for which it would need a layout improvement, power supply decoupling and ground plane routing, in addition to the low-pass filters mentioned above.

1 Like

Hi,
just some thoughts, because I am too using DaisySeed for Guitar. At the moment I have a breadboard setup only. I do think, that an adjustable input gain preamp is a good idea. Just have a small additional potentiometer knob for that. I use the onboard LED for overload indication. My personal opinion is, that for my applications some rare overdrive of the input is often better than constant background noise. In my setup for Teensy audio I use an Orange Squeezer compressor in front of the ADC. orangeschalt (musikding.de)

If you are at improving the Terrarium PCB, than I would also suggest to bring out the valuable second channel. It could be used for stereo or completely independently as Send-Receive.
Christof

Hello Christof,

I still don’t know exactly what I’m going to use DaisySeed for, at the moment I’m just playing around to see what possibilities it has. I’m going to consider using the two inputs and two outputs (it’s a waste not to use them) and also add a MIDI port and maybe a true bypass relay.
Another limitation I have seen with the Terrarium is that the TL072 clips the signal due to its power supply being only 5V. The PCM3060 codec can deliver a signal with peak-to-peak amplitude of 0.8 * Vdc = 0,8 * 4,5 = 3,6 Vpp, i.e. 1,6 V peak, whereas the TL072 starts clipping at 0,9 V peak.
I think this shouldn’t be a problem (we can always limit the output signal to the level that suits us), the problem comes from the fact that with such a high output noise level we need as much output level as possible to have a good S/N ratio.
It is possible that this new Rev7 revision is especially noisy, I don’t know if it is due to the PCM3060 itself or to a worse track and/or ground routing. I will try to get an earlier revision to check and get a better understanding.

Greetings