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?
No, I haven't come across that measure. I'll look into it.
I am not sure that Limit of Detection is an appropriate measure when trying to detect impulsive signals against a noise background. Detectability is usually considered to be based on S/N ratio but even that is a tricky measure in acoustics. Noise level could be the broad-band noise level across the full recording spectrum - which is relevant if trying to detect signals in the time domain - e.g for a zero-crossing detector, but detectability in a sonagram is different because you are looking at signal against a noise level within an FFT frequency band and so consideration of noise/sqrt(Hz) would be a better measure. But then for structured signals such as bat calls detection is not limited to a single frequency-bin but is distributed across the bandwidth of the signal. Couple all of that with the fact of having an uncalibrated microphone with a sensitivity that varies with frequency and it is clear that there is no simple measure which can define a limit of detection when applied to recording animals.
I am barely a novice at audio recording and this is all interesting, but it is going to take me some time to digest. I will try to motivate my reason for asking a bit more below (hopefully it helps):
I am simply trying to understand when is signal really signal. For example, if I build a spectrogram which has values in dB at what level can the AudioMoth produce a value that is real. If it varies in the frequency domain, that is fine. I simply need to throw away as much data as I can from our recordings.
Said another way: If I see a value in my spectrogram of -250 dB is that a number which could actually be recorded by an AudioMoth (at a given frequency).
@Barry Moore To give a definitive answer I would need to know a bit more about how you are using the AudioMoth. A measurement of the broadband noise level will give some indication, but that will also depend on the sampling rate (and therefore effective bandwidth) and the AudioMoth gain setting. Noise level will not strictly be proportion to the Nyquist frequency bandwidth because higher frequencies in the microphone and system will be aliased back into the bandwidth of interest. In practical terms, at 192ksps and lo gain, my background noise level (In Audacity waveform, log scale view) is around -50dB which is effectively the dynamic range of the recording. In a power spectrum averaged over half a second, the noise floor drops from -72dB at 1.5kHz to -82dB at 96kHz, but within that there are bands that are noisier, -67dB at 17kHz, -71dB at 36kHz and -75dB at 60kHz with a 'whistle' artefact of -73dB at 75kHz. (Reducing the input gain in the AudioMoth - a hardware mod, should give an increase in dynamic range but I have yet to try it out). On top of all that is the problem of clutter as opposed to noise - i.e. audio signal which is not from your desired target. Walking through long grass produces lots of noise, equipment goes chink, all sorts. Detecting genuine signal is then much more a problem of pattern recognition in a 2-dimensional image (the sonagram) and that is a whole different ballpark. On the other hand sensitivity - i.e. maximum detection range at which you recognise a 'pattern' is also a function of frequency being affected by the microphone frequency response (see the Knowles data sheet) and atmospheric absorption. Basically trying to put numbers to all of these is not wonderfully helpful, but in general the AUdioMoth is comparable to other recorders on the market apart from the more limited dynamic range, and for identification purposes overloading is not a severe problem, although it matters if you want to study signal structure.
Buy best USA made cat5e plenum, cat6 plenum Cables, Fiber optic Cables ,Coaxial cables and network management tools. http://atscables.com/