Generating Sweep signal

[PiezaKake]

Hi,

I would like to generate a sweep signal 10-80 kHz and then feed it to an AnalogOutput(DAQmx). The aim is to play back the signal and make sure that two ultrasonic microphones I am using have the same frequency response. Is it possible to generate such sweep in Bonsai?

Thanks in advance

[bruno-f-cruz]

The easiest would be to use the FunctionGenerator operator. Set the buffer size to match the resolution of the frequency update you need, and progressively increase the frequency by externalizing the property. If you need something more bespoke I would probably just generate the full waveform in Python and load it in bonsai using MatrixReader.

[katjaReinhard]

I have a very similar question and would like to generate an auditory sweep as well. I've tried FunctionGenerator but none of the things I tried to modulate the frequency property worked. Could you please provide some more input on how you'd change e.g. from 10-80 kHz over a specific time frame? I tried Timer and Sample as well as several other things but couldn't get it to sweep. thank you!

[bruno-f-cruz]

This is a naive implementation but shows you how to sweep from 1-15khz in roughly 10 seconds. I am working with buffer sizes, but you should be able to define everything in time with some math.

<?xml version="1.0" encoding="utf-8"?>
<WorkflowBuilder Version="2.8.5"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xmlns:rx="clr-namespace:Bonsai.Reactive;assembly=Bonsai.Core"
                 xmlns:dsp="clr-namespace:Bonsai.Dsp;assembly=Bonsai.Dsp"
                 xmlns:al="clr-namespace:Bonsai.Audio;assembly=Bonsai.Audio"
                 xmlns="https://bonsai-rx.org/2018/workflow">
  <Workflow>
    <Nodes>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="rx:Timer">
          <rx:DueTime>PT0S</rx:DueTime>
          <rx:Period>PT0.01S</rx:Period>
        </Combinator>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="rx:Take">
          <rx:Count>1000</rx:Count>
        </Combinator>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="dsp:Rescale">
          <dsp:Min>0</dsp:Min>
          <dsp:Max>1000</dsp:Max>
          <dsp:RangeMin>100</dsp:RangeMin>
          <dsp:RangeMax>15000</dsp:RangeMax>
          <dsp:RescaleType>Linear</dsp:RescaleType>
        </Combinator>
      </Expression>
      <Expression xsi:type="PropertyMapping">
        <PropertyMappings>
          <Property Name="Frequency" />
        </PropertyMappings>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="dsp:FunctionGenerator">
          <dsp:BufferLength>441</dsp:BufferLength>
          <dsp:Frequency>14985.1</dsp:Frequency>
          <dsp:Waveform>Sine</dsp:Waveform>
          <dsp:SampleRate>44100</dsp:SampleRate>
          <dsp:Amplitude>100</dsp:Amplitude>
          <dsp:Offset>0</dsp:Offset>
          <dsp:Phase>0</dsp:Phase>
        </Combinator>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="al:AudioPlayback">
          <al:SampleRate>44100</al:SampleRate>
          <al:State>Playing</al:State>
        </Combinator>
      </Expression>
    </Nodes>
    <Edges>
      <Edge From="0" To="1" Label="Source1" />
      <Edge From="1" To="2" Label="Source1" />
      <Edge From="2" To="3" Label="Source1" />
      <Edge From="3" To="4" Label="Source1" />
      <Edge From="4" To="5" Label="Source1" />
    </Edges>
  </Workflow>
</WorkflowBuilder>

[katjaReinhard]

hi, sorry, your response got lost in my inbox. it's quite a large script by now (attached), but I also copied a screenshot of the auditory part. you can find this section in the ThreatStimuli node. The timestamps of the camera are attached (60 Hz) and the auditory stimulus started at 09:39:16.467. The weird thing is that we repeat the auditory sweep twice right after each other and the frame loss only occurs during the first sweep. in this particular case, for example, I have a camera time stamp at 09:39:16.45 and then the next one at 09:39:17.268 but from there it continues normally. Each sweep should last for a bit more than a second, so clearly only the initial part of the first sweep is a problem. any ideas what we are doing wrong are very much appreciated!
auditory.zip

[banchan86]

Ooh yea this is a bit of a toughie to troubleshoot with so many things going on so if anybody else has any ideas feel free to chime in. Some thoughts:

1. You said the camera was recording at 60Hz, but unless i missed something the timestamps indicate the video frames are being produced at 120Hz (while the video writer is set to 60hz). Your videos will be playing at half speed/double the length, and it could also lead to weird buffering issues. I would check all the other camera timestamps/videos too. Fixing it may lessen the load on the system. Edit: I see now the frame index and timestamps are just duplicated, might want to fix that but yea I don't think it's an issue at least for the problem you are having

2. When you subscribe to a node, the startup cost of initializing that node is paid at the moment of subscription. In the top level of ThreatStimuli you have used SubscribeWhen to start a bunch of stuff at a certain point in the workflow. I'm not sure but my best guess is that those initialization costs are overwhelming the system at that point. I suspect you might see the frame drop even if you disabled just the auditory sweep but kept all the other stuff (and that could be one way of testing that out). That may also be why you don't see it on the repeat as those costs have already been paid. Unfortunately, if that is the case, it might require some heavy modification of the workflow.

3. I tried isolating just the tone playback but couldn't get it to play (bruno's original played for me). I don't have as much experience with audio playback but just wanted to make sure that you verified playback somehow. Is it 1-20khz in 1 sec?

[katjaReinhard]

thanks for giving it a try! indeed the csv file is written at the refresh rate of the monitor, not of the camera. We have used this script including the same SubscribeWhen structure to select between different stimuli for hundreds of experiments and haven't had any issues with frame loss. only when we added the small auditory module we suddenly saw this issue. we also don't see any frame loss when using this script (with the auditory stimulus) but a visual stimulus is selected in the ThreatStimuli node. It really seems that initiating the use of the speaker somehow causes an issue (RAM and CPU usage look fine).

The tone goes from 17kHz to 20kHz - in my lab only the master students can still hear that :D If you want to hear the tone, you can change RangeMin and RangeMax of the Rescale node to something more audible.

I'll try adding a delay inside SweepToneRoi, right before SweepTone. If it is really the flow and not some weird hardware-interaction issue then we should see the frame loss shifted relative to the onset of the auditory stimulus. if we still see the loss at onset of the stimulus, it must be something specific to addressing the auditory output...

[banchan86]

Ah thanks for the clarification. Yep that confirms I am old :P

Could you also try just isolating the audio/camera parts of the workflow like in the workflow I attached? I used a timer to initiate the sweep I don't have access to a Basler camera, but if we can verify that there is some weird hardware interaction, it might be worth raising an issue on either of the package repositories to investigate it. With my generic webcam I don't see any frame loss.

audio_camera.zip

Edit: Also minor point I noticed throughout the workflow you used the regular Timer instead of the Timer from the Bonsai.Shaders package, I think in general we recommend using the Timer (Shaders) which is synchronized with the render loop when presenting visual stimuli (or when aligning audio/visual stimuli in your case)

[katjaReinhard]

thanks for the advice on the Timer! I'll check that out.

I actually did write a very simple version just with the sweep and my webcam and I didn't see the problem either. For the complex version with 3 basler cameras, I have (temporarily) solved the problem by adding a 2s delay after the "RepeatCount" in the SweepToneRoi node. This still doesn't tell me if it's a hardware or software problem, but like this I don't get any lost frames, not when the auditory stimulus is selected with the SubscribeWhen nor when it starts playing 2s later. Since we trace the timing of the stimulus with our photodiode, we don't care about these extra 2 s.

If I find out more on whether this is a hardware problem, I'll definitely update here.