Hi folks, In my case, I could see the port, but not communicate with it, even after adding the custom rule. So I did some further digging. 1. On an Ubuntu 18.04 it appears the rules file should be placed in the '/etc/udev/rules.d/99-audiomoth.rules' file path. The difference here being that on the Ubuntu 18.04 operating system, the path '/lib/udev/rules.d/' is reserved typically for system installed rules. It means that if you update you operating system, this rule may be removed. 2. After adding the rule above (in the correct location), the command 'sudo service udev restart' is required for the rules to be reloaded. 3. Then you need to remove the device and plug it in again, for the rules to apply. At this point you can try to flash the device again. 4. If this still fails, check out your account privileges, by finding out what permissions the port requires, by running 'ls -la /dev/ttyACM0' or which ever port your device appears with. This command lists the files which match the '/dev/ttyACM0' and shows the file attributes ian@xxxx:~/Documents/AudioMoth/Flash$ ls -la /dev/ttyACM0 crw-rw---- 1 root dialout 166, 0 Jan 8 16:37 /dev/ttyACM0 then, by running the command 'groups' I get a result along the following lines, (on a relatively clean Ubuntu system) ian@xxxx:~$ groups ian adm tty dialout cdrom sudo dip plugdev lpadmin sambashare Now, I found that I wasn't a member of the dialout group originally, and had to add myself to that group to get the permissions. This typically would not be required, if the rule was behaving itself. sudo usermod -a -G dialout $USER After adding yourself to the group, logout and then log back in. If upon logging back in you're not seeing dialout appear in the 'groups', then reboot the machine. 5. Finally, I have found running 'flash -i /dev/ttyACM0' 3 times, to be a very consistent way to ensure I establish communication and get the serial number, before I try to 'flash -u /dev/ttyACM0 AudioMoth-1.2.2.bin' the device. It's almost like 3 times, is just the magic number that makes it work for me. 2 times, is not enough. As a result, my flash script looks like: flash -i /dev/ttyACM0 && flash -i /dev/ttyACM0 && flash -i /dev/ttyACM0 flash -u /dev/ttyACM0 Audiomoth-1.2.2.bin

Appears that your flash command is not being executed inside the specified directory. (I’m ignoring the minor typo in Audio) open terminal app cd ~/Desktop/AuidoMoth make sure that the command working directory is changed to the directory supplied. chmod a+x flash ./flash -i /dev/ttyACM0 substitute ACM0 for the device path as found when connected to the USB port, the paper clip is connected, and the switch moved to the custom position. Find the device by running ls -l /dev/tty* before and after connecting the device. the new device will be appear is the list after the device is connected.

May I please enquire which board you folks are checking your firmware with? EFM32WG-DK3850? The uMoth has piqued my interest. Is the wonder gecko chip still planed to be used for the new board?Any chance there are some pins there to extend the device? Thanks :)

I’ll try the Logfile approach first and then fallback to the EFM32 debug boards if it’s still going sideways. I have implemented some unit testing via Unity within my firmware. It has provided additional assurance that the USB changes which are being made are correctly defined. The idea to extend the project with a test harness is an interesting concept. I've also briefly attempted a C++ port of the firmware to assist abstraction and isolation for similar reasons, providing a test surface, removed from interrupts and EM4 woes. If this goes anywhere positive I’ll let the community know.

Have been having the same issue as described above. Can confirm that running the command to get the serial number twice before uploading the new firmware was a successful workaround. sudo ./flash -i /dev/ttyACM0 Serial Number: 24A0xxxxxxxxxxxx sudo ./flash -i /dev/ttyACM0 Serial Number: 24A0xxxxxxxxxxxx Then running sudo ./flash -u /dev/ttyACM0 AudioMoth1.2.1.bin Programmed: 45912 bytes Flash CRC: 99F5

Hi Mugsey, Did you pursue this technique to stream data over USB? I'd be interested in working with you to modify the firmware and get the data to be streamed. Let me know if you have an interest. I'm planning on keeping the SD card to store the data locally, then intermittently reading from the SD card, after the file is written. This way, if the Raspberry PI runs out of power, and batteries are installed in the AudioMoth, the unit will continue to record per the schedule. I appreciate that there are other devices which can perform this simpler, however the device signal to noise ratio and ultrasonic recording capabilities make this a superior alternative currently in my opinion. Ian