©2019 Open Acoustic Devices

Aug 3, 2017

Trial unit

9 comments

I have received my trial unit and downloaded the app, on setting up the unit the time does not set, please can you tell me where I am going wrong.

 

Regards Pete.

 

Aug 4, 2017

Hi Pete,

 

That's strange, we checked them all before shipping. Can you describe what happens. Is the switch in the USB position? Are you using the AudioMoth Configuration App? Which OS are you using?

 

Alex

 

Aug 4, 2017

As a follow-up, can you see the time on the device changing when you connect it to the USB cable with the app open? The time should initially be greyed out and reading 00:00:00 01/01/1970. As soon as the AudioMoth is plugged in it will update to whatever the AudioMoth initially thinks the time is and the text will turn black. The initial time will be the number of seconds it has been powered up, and you should see this changing every second.

Aug 4, 2017

Here's a screen shot. It will also read the ID of the device and show the battery state. This one has no batteries inserted and is being powered by the USB cable.

 

Aug 4, 2017

Hi Alex,

 

I am using windows 10 and the switch is set to usb, using the app I set the start time, finish time, sample rate and gain, pulse and duration, then plug in the usb, if I am understanding correctly the time should now set, this dose not happen and when I place the cursor over the Configure Audiomoth I get a no entry sign.

 

Regards Pete

Aug 4, 2017

You can plug in the USB at any time either before or after changing the settings. As soon as the device is plugged in though you should see the time update (change from grey to black) and start counting up every second. If the time display is still greyed out, that is why it isn't letting you push the configure button. With the app closed, try plugging in the device. Does the green LED come on? Check that Windows hasn't popped up a window and is looking for a driver before it will allow you to use the device.

Aug 4, 2017

OK I will try this when I get home lunch time and get back to you, is there a phone number that I can reach you on.

Regards Pete

Aug 4, 2017

Yes, just sent you an email.

Aug 4, 2017

Hi Alex,

I have installed the app onto another laptop and it works OK so there must be something conflicting on my other laptop, many thanks for your help, please can you let me know when purchases are available.

Regards Pete.

 

Aug 4, 2017

Great. We'll see if the same happens to anyone else and try to figure out what might have conflicted with it. The first group purchase coordinated by ZSL will open on 1st September so keep an eye out here for details and also on the WILDLABS.NET forum - https://www.wildlabs.net/community/thread/364. We're hoping to have a housing available by then as well.

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.