Hi Chris,
It looks like we’re ready for next steps in replacing the NI DAQ. I was wondering if you have example code for Arduino that can achieve the same functionality of the current NI DAQ?
The two functions I need are: (a) convert Mac serial USB signals to digital pulses, and (b) signal the reward system. In case it helps, here is the current MWorks code snippet that communicates with the NI DAQ:
nidaq daq (
name = Dev1
update_interval = 3ms
analog_input_data_interval = 1ms
analog_output_data_interval = 1ms
autostart = true
) {
nidaq_digital_output (
port_number = 2
num_lines_in_port = 8
line4 = reward_line
line2 = experiment_state_line
line0= stim_start_line
)
}
Thanks again!
Yoon
Hi Yoon,
Here’s the Firmata equivalent of your NIDAQ code. The pin numbers are just examples. Any digital I/O pins will work:
firmata daq (autostart = true) {
firmata_digital_output (
pin_number = 2
value = reward_line
)
firmata_digital_output (
pin_number = 3
value = experiment_state_line
)
firmata_digital_output (
pin_number = 4
value = stim_start_line
)
}
That should be the only change needed to get existing experiments working with the new hardware.
Cheers,
Chris
Thank you, Chris!
I will try this out and will keep you posted (“StandardFirmata” example on Arduino (Nano 33 BLE)).
Best,
Yoon
Hi Chris,
I’m pleased to let you know that Arduino worked on rig 2. I saw the digital pulses and the reward system worked. I will upgrade the Mac OS to the latest once I get a go-ahead from other lab mates.
Thanks for your help!
Yoon
Great! Thanks for letting me know.
Chris
Hi Yoon & Alina,
While testing the Arduino Nano 33 BLE, I’ve discovered that communication with the board can be unreliable. Specifically, messages between the board and the connected Mac are sometimes truncated, meaning commands sent to the board (e.g. to change a pin’s state) can be lost. It doesn’t happen all the time, and it’s most apparent when you try to configure multiple pins at once (such as when using a word output channel). However, it’s very easy to induce with my standard Firmata tests.
This appears to be a known issue in the software stack for the board. There doesn’t seem to be any fix or workaround at present. While I expect the issue will be fixed eventually, I think the best course of action for now is to switch to a different board.
The most obvious choice for replacement board is the Arduino Nano 33 IoT. It has the same form factor and pinouts as the Nano 33 BLE, so it should work as a drop-in replacement. However, the IoT’s microcontroller and software stack are completely different from those of the BLE, so the BLE’s USB issue won’t affect it. In fact, the IoT uses the same type of processor as the Adafruit Feather M0 Bluefruit LE, which I’ve used for many years as an MWorks Firmata device via both USB-serial and Bluetooth.
Does this sound like a good plan to you? If so, I’ll ask Chris to order one Nano 33 IoT for me. Once I’ve tested it and confirmed that it works as expected, we can get more for the lab.
Thanks,
Chris
Sounds good to me. Would be good to get going asap, I cannot use rig 4 without this, meaning I cannot train my animals.
Very happy that you tested this and that I didn’t have to figure this one out myself!
I’ve now tested the Nano 33 IoT, and it appears to work perfectly. Also, the Firmata library already supports it, so you should be able to use the standard setup instructions without modification.
I say go ahead and get some more!
Chris
I installed one in my setup, it required more installations on Arduino and computer restarts but generally speaking no big deal to switch.
Hi Alina,
I installed one in my setup, it required more installations on Arduino and computer restarts but generally speaking no big deal to switch.
I’m glad the switch went OK.
While you certainly need to install a core for the board the first time your program it, I don’t understand why you would need to restart your computer. Quitting the Arduino IDE and disconnecting and reconnecting the board should be all that’s required after installing the firmware. Did you try that and find that MWorks still wouldn’t connect to the board?
Chris
Yes. I even disconnected and reconnected the board twice since this is faster than a restart. But I think it had the old board in the system still somehow, it also still showed in the Arduino software in addition to the new board. After it worked I also did another restart to see if it works immediately now. And after that restart I still had to disconnect and reconnect the Arduino another time before the mworks test worked, even though it ran before that restart. I don’t know yet if that has to happen every time, I hope not. I will let you know if I always need to do this.
Hmm. I’ve never seen this before, and I have no idea why it’s happening. If/when I’m ever back in the lab, maybe I can take a hands-on look at the issue and try to figure out what’s going on.
Thanks,
Chris
Hi Alina and Chris,
I’ve revisited Alina’s observations with Arduino Nano. I could replicate her case by restarting the Mac. After rebooting, I noticed Arduino’s Nano was not automatically mapped to one of Mac’s device ports (e.g. /dev/cu.usbmodem201). Luckily, the device was mapped once I pressed the white button on the Nano board (and “woke” it up). So, I guess the solution is to press the white button on the board after each reboot.
Best,
Yoon
Hi Yoon,
Thanks for the additional info. I still can’t reproduce the problem, at least on the 24-inch M1 iMac I have at home: If I leave my Nano 33 IoT connected and reboot, it’s still available via the same device handle after the restart, and MWorks can connect to it as usual.
Whenever I’m back at the office, I would like to see this issue in action. But I’m glad you’ve found a relatively simple workaround to use in the meantime.
Cheers,
Chris