The goto program for audio measurement in the Internet age is RightMark Audio Analyzer (RMAA). It’s not an easy program to use in isolation, and is used best with some old-skool analogue technology. In particular, it doesn’t really do absolute level in any way – everything is referenced to 0dBFS.
RMAA testing is deconstructed by NwAvGuy here. His thesis is that it is impossible to use RMAA right. particularly if you have no experience of analogue electronics and no other test gear. And I’m guilty as charged of publishing RMAA test results on the internet 🙂
It saddens me a little bit that measurement has now become go out and buy £x,000 worth of test gear, plug it it, attach to D.U.T. press the button and report the result. And if you can’t do that, well, no Audio Precision test kit, no comment. I’m not dissing NwAvGuy’s observation – it’s the loss of other ways of testing audio gear I regret. I don’t test for distortion – I scan for it. That’s because I’m testing finished gear usually for how noisy it is with mics at low levels. If distortion/frequency response looks okay/reasonable with RMAA that’s great, if it doesn’t I look for what I have done wrong in setup. Most manufacturers get the distortion and frequency response basics right, but mic preamp noise does vary because most audio recording is music and therefore has plenty of signal, so preamp noise is not usually a key parameter in a field recorder.
Way back when I was working at BBC Designs, using their EP14/1 test set things were a little more from first principles than ‘press the button of this expensive gear and report back’. The EP14/1 was basically a tone source and a meter with a precision attenuator in front of it.The meter was used comparatively – you would adjust the attenuators to make it read the same as a reference reading, and the wanted information was in the different setting of the attenuators. This way any nonlinearity of the meter scale was greatly minimised. Continue reading “Audio Measurements and beyond rightMark”
The smartphone/iDevice is the preferred window to the world of many people – it’s small, it’s handy, it does everything. It’s always with you. And it will do field recording, of sorts.
The internal microphone is usually a noise cancelling microphone designed to favour nearby sounds over ones far away – usually by letting ambient sounds sneak onto the back of the mic capsule to cancel out the ambient sounds impinging on the front. You, being closer to the front and shaded from the back cancel out less. Crude, but it sort of works.
Use an external microphone, not the handset one
That’s not where you want to go as a field recordist, indeed if you could discriminate against your fumbling and breathing noises you’d be better off 🙂
You want to be able to use an external mic. Omni for general run and gun ambient drive-by recordings, and a directional/shotgun mic if you want to pick out a particular birds. To use the latter well you need to be able to hear what you’re doing. Shame, is one of the big failings of smartphone audio is that your can’t record and monitor at the same time. It’s not unreasonable, you rarely want to hear that much of yourself in a phone conversation.
You need an external adaptor lead to convert the 4 pole headphone socket to a stereo headphone + mono microphone connector, these are cheap enough on ebay
You can’t do stereo microphone recording this way, it’s mono only. The input provides plug-in-power to energise electret mic capsules, because this is the typical active device in a phone headset.
Testing frequency response and sensitivity
I tested the frequency response using Rightmark audio analyser, and it looks good enough
Going in with 1k tone at -67dBu and 150Ω source impedance the tone level was -32dBFS RMS and with the tone off the signal was -70dBFS RMS implying a self-noise of -105dBu [ref]44.1kHz sampling, 22kHz BW, PCM, manual gain using the app SpectrumView[/ref] Which is acceptable for urban field recording, though not stellar.
Big FAIL in the field – no monitoring
The big trouble, however, is that you can’t hear anything through the headphones, so you can’t aim a directional mic. Which makes the whole rig a bit crap to use in the field, and this doesn’t seem to be fixable.
There are other bits that grate – for instance the iPod doesn’t always pick up there’s an external microphone, so you can end up viewing the internal mic instead. Then there’s the usual rattiness of apps all round, about 1 in 30 times it just hangs outputting trash on the screen. In general, as a field recorder, smartphones suck. They can be used, but anyone who has used a real field recorder will miss the positive action of real buttons, real record level controls, real metering, and yes, being able to hear what they are doing.
Being able to watch a live sonogram using spectrumview is pretty awesome, and it’s a good sonogram, too, quite well suited to general bird sounds.
The best of all worlds, use a field recorder before the iPod!
It is not done well; but you are surprised to find it done at all.
Best not argue with Dr Johnson 🙂 As a recorder my iPod was flaky and with an input noise level some 20dB off what it could be and mono it’s nothing special even when it does record.
You can get the sonogram by feeding the iPod or smartphone/i-Device downstream of your field recorder – simply use a headphone y-splitter out of the recorder with one side going to your headphones and the other to the iDevice input, and set the gain of the iDevice waaaay down. You don’t have to record with it.
You now have a reliable recorder, decent mic preamps, you get to monitor what you record and if the iDevice throws a wobbly then you still have a good recording. But you how get a lovely spectrogram in live real-time. This is something that’s really excellent. In an ideal world the spectrogram would be built into the field recorder, however running it really hammers battery life so it’s good to have it optional. And it needs to be in colour.
Mill Stream is a local nature reserve running along the boundary between Rushmere St Andrew and Foxhall Heath, starting from Rushmere Golf course and running through to Foxhall Road dip, opposite the Nuffield Hospital. I started from the Brendon Drive access parking my bike there – there is no car parking for this local nature reserve, and followed the Jubilee path marker 12
There’s some interesting local history – the large Oak trees mark the boundary between the parishes.
Goldfinch flock feeding near the old shooting range
Further towards Bixley there was a Boer War/WW1 shooting range, with the large sandbank there to catch any stray projectiles. Apparently brave souls hoisted targets above the wall that gave them some protection.
Robin, with long-tailed tits flock at the start
The reserve is surprisingly quiet, particularly at the northern end, though you’re never that far away from human habitation here.There are some muddy parts to the path where it runs close to the stream, particularly at the Rushmere common end.
It gets noisier towards the Foxhall Road Dip – the path does carry on across the road but it’s a fast road and visibility is dreadful.
This was a pleasant little gem – I’d driven past the Foxhall Road dip many times for years without knowing this was here
If I will show up at noon I’m not going to see/hear that much 😉
dogs: present. Should be on leads according to the leaflet to avoid disturbing the wildlife
condtions: mostly dry but some parts were muddy across the width of the path. You don’t need wellies but decent walking boots help.
Is covering a 12-acre farm with WiFi a reasonable idea? If so, I could run multiple cameras, say have one on the cows and one on the pigs, all connected to a central location, On the upside, the farm is roughly square and with a mild slope to the ridge at the top. Everything is pretty much line of sight. On the downside, there’s no good central location, which would be the obvious way to service the farm with 2.4GHz WiFi. Distances are long – the field is about 250m wide/long, and I could easily pick up a 300m path length feeding from the edge.
Earlier experiments showed that I could in theory use native WiFi, using a router to receive BTFon from a broadband connection in the town over a high-gain antenna and redistributing it from a WiFi AP. The trouble is I am desperately short of power – every extra piece of kit means more frequent battery changing. In the end I went with a more powerful MiFi access point – one that supported an external WiFi aerial. I used a 9dB TP-Link patch antenna
This feed the farm from one edge, as it happens the antenna is furthest away from the most likely camera sites but slightly higher than the target sites. The signal pattern fans out quite well, serving the likely points of interest. I was chuffed with the performance of the aerial – it gives the right balance of directionality, as I don’t need to bother to serve the field behind me, but it gives very useful gain in the wanted direction – I can just about get a wifi connection with the internal antenna of my iPod touch from the opposite corner of the field. As the forest garden and some of the windbreak trees grow I may experience problems, but that is for another day. By then perhaps we have a site with mains power 🙂
For the MiFi unit I used a TP-Link MR3220 – it’s surprisingly hard to find a MiFi box with an external WiFi aerial socket, because not unreasonably they anticipate you using this sort of thing as a personal cloud. I had to live with the 9V powering and used a Chinese Ebay 12V to 9V converter switchmode converter to efficiently turn the 12V battery power to 9VDC
The other part of improving range is to upgrade the camera end with a WiFi card with an external rather than internal antenna; since the Pice case has been withdrawn I need another solution for that. The PICE case also still exposes the Raspberry Pi camera lens to the elements which is Not a Good Thing leading to the lens haziness problem.
It doesn’t really matter how big the camera is, so I took the opportunity of using a much larger box – a Hammond case 1599 to fit it all in.
If you’re going to put something outside then the fewer holes you can drill the better, hence the use of sticky pads and cable ties as mounts, and the single 2.1mm power socket on the base, so water could drain out that way if necessary, and could be standing 0.5cm without affecting the electronics.
The case has several mounting lugs in the lid, but in the end I will have to drill a hole for the camera. I placed an O ring on the case and a microscope slide pressed down by foam and the camera to make a watertight seal but keep the elements out of the lens; that way hopefully I get to either clean or replace the microscope slide after a season is out rather than the camera.
The 12V to 5V converter is mounted in the case; that way any cable losses aren’t too bad and the current in the supply cable is reduced, it is about 200mA max.
Setting it up in the field
The paving slab is there because the first version of the tripod ended up flat on its back in the morning. At least the construction can survive a fall of 2m. Perhaps the neoprene sunshade and the extra area at the top of the pole presents too much wind loading.
Controlling the Pi
I postulated all sorts of complex feedback when first considering this, letting the Pi tell the microcontroller to turn the Pi off with a GPIO pin, but it’s been massively simplified. A microcontroller powers up the Pi, and pulls the power after 5 minutes. Then it waits 10 minutes and does it again, provided that the 12V supply is enough (>11.5V) and it is daylight.
I use similar Python code to the first cut, but this time I start running the takepic.py camera code on startup. I look for a switch closed on the GPIO, and if so, abort uploading the picture because the Pi is in service mode1. This switch is a reed switch mounted on the inside of the case and activated by sticking a magnet to it, this saves a hole. It lets me get onto the Pi and configure it. Normally the switch is open, in which case the Pi tells the system to do a shutdown in 4 minutes, which is enough to connect, get Wifi network DHCP and SFTP the picture to the website. 5 minutes after powerup, the microcontroller managing power pulls the power from the Pi.
The shutdown command on the Pi minimizes the chance of corrupting the SD card, and the picture is written to the /run/shm/ ramdisk prior to uploading, since there is no point using up SD card write cycles with ephemeral data like that.
#$Id: takepic.py 58 2014-11-06 20:54:02Z ermine $
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD) # USE Pi BOARD pins, not the BCM ver
GPIO.setup(7, GPIO.IN, pull_up_down=GPIO.PUD_UP) # 7 is next to gnd on pin 9, so set pull up
remotename='WEBSITE.COM' # assuming this is reachable by ssh and www
with picamera.PiCamera() as camera:
#camera.resolution = (2592, 1944)
# The following is equivalent
#camera.resolution = camera.MAX_IMAGE_RESOLUTION
# run half res to test out connectivity etc and save money
#camera.led = False
camera.resolution = camera.MAX_IMAGE_RESOLUTION
#camera.resolution = (1296, 972) # do half real to eliminate Bayer softness and save TX bandwidth
camera.capture(DIR+imagename, resize=(1296,972), format='jpeg', quality=20)
except picamera.PiCameraError,e :
time.sleep(10) # hopefully nw is up by now
#print "will shutdown"
os.system("/usr/bin/sudo /sbin/shutdown -h +4 &")
if not(camerafail) :
while (not timedout) and not connected :
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
except socket.error,e :
counter += 1
if counter >= 5:
print 'Failed to connect to ',remotename,' ',datetime.datetime.now().strftime("%y/%m/%d %H:%M")
if not timedout:
print 'ftp image starting ',datetime.datetime.now().strftime("%y/%m/%d %H:%M")
ssh = paramiko.SSHClient()
ssh.connect(remotename, port=2222, username='USERNAME', password='PASSWORD')
sftp = ssh.open_sftp();
print "closed SFTP"
except paramiko.AuthenticationException,e :
except socket.error,e :
print "manually aborted by jumper 7 to 9"
This has massively reduced the power drain of the camera – it is < 200mA for a third of the time, with an outage during the night of about 1/3 of the time, so about 1/3 × 2/3 × 200mA average, ie ~50mA. The original power drain was about 300mA 24×7.This power drain is much less than an electric fence which is usually about 150mA, so it could be used from the fence battery, which would then let us monitor the fence battery voltage as a bonus.
It also suits solar panel charging well, as the power drain is proportional to day length. The WiFi node draws more (a sustained 200mA during the day) but at least it is just one place where the battery needs changing more often – about once every two weeks. That’s livable with, but if I’d used a WiFi long-distance connect and a WiFi high power AP that would be shortened too much, particularly as logging into BT Fon would require another Pi to keep the connection open. GiffGaff run about £7.50 per Gb PAYG which isn’t bad.
So far so good. The new pigcam
works all over the likely sites on the farm
concentrates the data through one GiffGaff SIM[ref]data service gets cheaper with volume, so this is much better than each camera having a SIM[/ref]
reduces power at camera sites to minimal
lets me add more than one camera to the system
which is a success compared to the single site version which had a very high power drain because it wasn’t being power-managed.
In service mode I get to ssh into the Pi to configure it, and issue the shutdown command manually – I bypass the microcontroller shutdown for that ↩