©2019 Open Acoustic Devices

Jan 22

SD card error message, no programmable recording

6 comments

Hi all- Just purchased 2 Audiomoths from Labmaker, and I'm starting to test them out. One of the devices does not seem to take the programmed parameters (60 second recordings, 5 second wait, from 2000-2030, 2100-2130, 2200-2230, 2300-2330, LED OFF). After I program and set the switch to custom, both LEDS flash, telling me its a bad card. I've tried other cards, and it does the same with them. If I go to default, the recording function works. Ideas? The other Audiomoth is working correctly. I've contacted Labmaker but not heard back yet-

Thanks much-

Eric

Hi Eric,

 

If the two LED flash immediately when you switch to CUSTOM mode, but the device records fine in DEFAULT mode, then the flashing is probably indicating that you haven't set any active recording periods, or haven't configured the device at all.

 

A bad SD card write will only be indicated by the LED when the device actually tries to start making a recording. Set a recording period some time into the future and check what happens. If the device if okay it will flash green indicating that it is waiting to start recording. Double check that the time is being set correctly in the configuration tool and that it is increasing properly.

 

Alex

Thanks for the response Alex- I've gone back to both them and reprogrammed them the same - One takes the programming and records as intended, the other just gives bright green and dim red blinks when switched to Custom. It does not record. Faulty unit, or are there other tricks I should be trying? I've taken out batteries, tried other cards, etc.

Eric

It might be worth reflashing them with the most up to date firmware (1.2.0) and using the up to date configuration app (1.2.1) to double check that the firmware isn't corrupted in some way. If it makes a recording fine in DEFAULT mode then the SD card connection must be good, and if you can see the clock changing in the configuration app then the real time clock is set and running which is the other potential source of the error flashes.

 

It could be losing the time setting when the USB cable is disconnected and it swaps from USB to battery power. Try configuring the device and then with the USB cable still connected switch to CUSTOM mode and try to make a recording without any batteries in the device.

Alex- I updated the configuration app from 1.2.0 to 1.2.1 and that seems to have done the trick. I performed a programmed 10 minute recording in 60 second intervals and it went well. The aberrant LED flashing has stopped. Thanks very much for your help!

E

Great. I'll try to figure out exactly what was going wrong since its a bit strange why one worked perfectly and not the other. What time zone are you in?

I'm in UTC-8 (California). Thanks again for the help-

E

New Posts
  • Hi, in all my recordings there's a "clicking" noise (26-28kHz). This is an issue that I had before with some recordings but now the noise is louder and it is present in all recordings. The batteries are Energizer AA (new) and the SD card is the SanDisk Extreme 32GB. Is there Anything I can do to make the "clicking" noise disappear?
  • Amazing work! https://www.openacousticdevices.info/mmoth Clearly it is early days, but obviously so many questions pop into mind ... - Off board Lithium ion battery, with a onboad connecter? (So you can choose any size LiOn? or LiPo? like - https://hobbyking.com/en_us/turnigy-2000mah-1s-1c-lipoly-w-2-pin-jst-ph-connector.html ?) - Any Battery life / runtime estimates vs AM1.1? - Cost? Double side so more expensive? - etc, etc, etc ... Anything else to share with us yet??
  • Hi, I'm attempting to modify the basic firmware, and I'm progressing quite well however there are a couple of sneaky scenarios which require a lower level debugging capability. Can you please advise how you debug the firmware, on the device? I've modified the firmware to call 'AudioMoth_setupSWOForPrint' at the end of AudioMoth_initialise() and added a couple of debug statements such as printf("Debugging enabled"); Throughout the code, being executed. These changes, along with my other alterations were then successfully flashed to the AudioMoth device. I've then connected my J-Link debug probe https://www.segger.com/products/debug-probes/j-link/ , which appears to support the EFM32WG980F256 chip. https://www.segger.com/downloads/supported-devices.php 1. PC -> USB -> AudioMoth USB plug (normal USB connection for an AudioMoth) 2. PC -> USB -> JLink Debug Probe -> SWD via Dupont Connectors -> AudioMoth Debug pads Here's a couple of photos to highlight what I'm doing. Sure, those connections are soldered a little rough but have been verified to be fine. As a simple dump, here's what I'm using. I'm expecting you're doing something similar when modifying the firmware. JLinkExe SEGGER J-Link Commander V6.52c (Compiled Oct 11 2019 15:44:58) DLL version V6.52c, compiled Oct 11 2019 15:44:50 .... Type "connect" to establish a target connection, '?' for help J-Link> connect Please specify device / core. <Default>: EFM32WG980F256 Type '?' for selection dialog Device> Please specify target interface: J) JTAG (Default) S) SWD T) cJTAG TIF> S Specify target interface speed [kHz]. <Default>: 4000 kHz Speed> Device "EFM32WG980F256" selected. Connecting to target via SWD Found SW-DP with ID 0x2BA01477 Scanning AP map to find all available APs AP[1]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7 ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM ROMTbl[0][4]: E0040000, CID: B105900D, PID: 003BB923 TPIU-Lite ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM Cortex-M4 identified. J-Link> SWORead 0 bytes read (0 bytes in host buffer) J-Link> SWOView Receiving SWO data @ 4000 kHz. Data from stimulus port 0: ----------------------------------------------- Occasionally I'll get SWO output, but its all garbled and meaningless. On other hardware I would think this was a mismatch of the receiving clock (4000 kHz), but maybe I'm attacking this incorrectly. I appreciate this is getting down into the lower levels of core programming on the device but I suspect other users may wish to also understand these debugging aspects when modifying the firmware to suit their needs also. Without a device level debugging capability the only way to check out changes is to flash the device with extra LED flashes to highlight state changes, or log to the microSD via the AudioMoth_appendFile operation. Which SWO debug probe do you use to validate changes to the base firmware? What code changes do you make to enable debugging? Are there Simplicity Studio changes which you utilise to support debugging on the device? Are you debugging the code off the device instead, on a PC using a 32-bit ARM emulator or 32-bit x86 target toolchain? Are you implementing Unit Testing on your version of the firmware?
Before posting, be sure to check the FAQ.