Tag: Zaxcom

  • NP-50 & BT100 Battery life comparision in Zaxcom ZMT & ZMT-X

    I want to share some battery tests I did with the two Zaxcom ZMT transmitters:  ZMT4 and ZMT4-X.

    The ZMT4 advertises “up to 7h” battery life, and uses NP-50 batteries (same as Lectrosonics SSM).
    The ZMT4-X advertises “up to 16h” battery life, and uses Motorola BT100 batteries (only used by some unusual Motorola walkies as far as I can tell).

    I measured battery life by putting the transmitters into record, waiting for them to die, and then ingesting the recorded files.  The length of the recording is the time I used for battery life.  Transmitter power was set to 50mW.  For realism, I tested with a lav connected (DPA 4660).  I also tested two Countryman B6s to see if a different lav model affected battery life (but I screwed up the test, so keep reading).  All the transmitters were running firmware v4.59.

    I tested two NP-50 batteries:  One from Fujifilm, and Lectrosonics’ custom LB-50.  Both are manufactured by Panasonic, but come from different factories and have different UL codes.  The Fujifilm battery is certified under UL code MH27866, which identifies the manufacturer as “PANASONIC CORPORATION ENERGY COMPANY LITHIUM-ION BATTERY BUSINESS UNIT”.  Lectrosonics is certfified under UL code E341239 and manufactured by “Panasonic Energy (Suzhou) Co., Ltd”.  Both are rated for the same electrical specifications:  min. 940 mAh / 3.4 Wh and 3.6V / typ. 1000 mAh.

    I bought the Fuji’s about a year ago from Studio Economik, but they were probably old stock; I don’t think Fuji has actively sold them for a couple years.  They’ve been lightly used in the last year; I doubt they’ve lost much of their initial capacity yet.  The Lectronsonics LB-50s were brand new about a month ago.

    Sadly, although Zaxcom announced their own NP-50 Pro battery last month, I didn’t have any to try.  It’s worth noting that Zaxcom specs their battery at 900mAh vs. 1,000mAh for both the Fujifilm and Lectro equivalents, so on paper Zaxcom’s battery probably loses 10%.  It’s worth noting that Zaxcom lists “expected runtime” for the ZMT4 as “6 hours with a lav”, so they aren’t making the seven hour claim for their own battery. Zaxcom’s battery is about half the price of Lectro’s battery, and roughly equivalent to what I bought the Fujis for … but the Fujis no longer seem to be available.

    The BT100 is Motorola part no PMNN4468 (B) (the final letter apparently denotes revision, so any final letter should be compatible).  The batteries were brand new.  There are no generic versions of this battery available as far as I can tell, so I don’t have any other comparison.  There is no UL certification number on the battery, but it does list the following information:  Cell origin: China, Manufacturer:  Foxlink Automotive Technology (Kunshan) Co, Ltd., 3.8V / typ. 2300mAh.  Simple math converts that into 8.74 Wh.  That is 2.4x the size of the NP-50, which roughly corresponds to the ratio in claimed battery life:  The ZMT4-X’s 15h battery life spec is 2.3x the ZMT4’s 7h spec.

    All batteries were fully charged, but had sat for about a week, so not a fresh charge.

    Results

    Tx TypeBattery TypeLav TypeRecording time
    Zaxcom ZMT4Fujifilm NP-50Countryman B65:41
    Zaxcom ZMT4Fujifilm NP-50Countryman B65:47
    Zaxcom ZMT4Lectrosonics LB-50DPA 46606:43
    Zaxcom ZMT4Lectrosonics LB-50DPA 46606:47
    Zaxcom ZMT4-XMotorola PMNN4468BDPA 466015:49
    Zaxcom ZMT4-XMotorola PMNN4468BDPA 466015:00

    Observations

    Under ideal circumstances, the batteries do get pretty close to Zaxcom’s advertised runtime, which is great.  Both the ZMT4 and ZMT4-X came within 15 minutes of their advertised runtime — on the best case result.  For the ZMT4, it was within 3.1% of advertised runtime, for the ZMT4-X was within 1.1%.

    Here’s the part that I screwed up:  I inadvertently paired the two DPA4660s with the Lectrosonics LB-50s and the two B6s with the Fujifilm NP-50s.  And the B6 / Fujifilm combo gave almost exactly an hour less recording time than the DPA4660 / Lectrosonics combo.  Looking at the data alone, I can’t tell if Lectro’s batteries are fundamentally better than Fuji’s, if B6s are significantly more power hungry than DPAs, or a combination of both.  I suspect that Lectro’s battery is the major difference (my guess is they have an advantage in both age and manufacturing quality), but I can’t prove it.

    The NP-50 combos both performed similarly, but there was a pretty significant difference with the Motorola batteries:  15h even vs. 15:49.  In the grand scheme of things, that’s a 5% difference, which is probably not an unreasonable margin of error for the test, but it does mean you should probably be conservative when estimating runtimes (mostly based on variability in both cell quality and difference between different charge cycles).  I would definitely stick with the lower result when looking for practical runtimes (and this is where Zaxcom’s “up to” specification gets a bit suspect for me).  One other quirk of the ZMT4-X:  The battery telemetry doesn’t work super well.  Both my test units showed roughly 50% battery life well into the thirteenth hour of operation.  Presumably they fell off quickly after that, but I wasn’t watching closely.

    >6h battery life on a tiny ZMT4 means one battery change a day at lunch in most cases.  >15h on the ZMT4-X (roughly the size of a Lectro SMV) is phenomenal.  Practically speaking, it means no changes during the day.  If it dies, you should be well into triple-time on your paycheque.

    Historic Test

    One other point of reference:  I previously did a battery test with only the Fujifilm batteries.  But I did it with 8 different batteries, and I did it when I first got the batteries (i.e. they had zero charge cycles at the time).  The test methodology was slightly different as well:  I tested with no lav connected.  So, this test isn’t useful for comparing batteries, but it is an excellent way to gauge a confidence interval because I have a sample size of 8. 

    Tx TypeBattery TypeLav TypeRecording time
    Zaxcom ZMT4Fujifilm NP-50None  5:50
    Zaxcom ZMT4Fujifilm NP-50None  6:27
    Zaxcom ZMT4Fujifilm NP-50None  6:15
    Zaxcom ZMT4Fujifilm NP-50None  6:13
    Zaxcom ZMT4Fujifilm NP-50None  6:18
    Zaxcom ZMT4Fujifilm NP-50None  6:37
    Zaxcom ZMT4Fujifilm NP-50None  6:15
    Zaxcom ZMT4Fujifilm NP-50None  6:12

    What I get from this is that the original Fujifilm test was mostly clustered around 6:15 runtime with a couple outliers in both directions.  That’s about 30 minutes more than the more recent test.  What does that mean?  Hard to say.  It could mean the Fujis perform better on a recent charge (the original test was fresh off the charger; the more recent test they had sat for a week).  It could mean the Fuji’s have lost of bit of their capacity as they’ve aged in the last year.  And it could mean the B6 really is a bit power hungry.

    What does seem likely is that the Lectrosonics LB-50 really is a better battery than the Fuji.  The LB-50 tests were done at a similar stage in battery life (i.e. new), and had the dual disadvantages of having sat for a week and having to power a DPA4660 lav.  Despite those disadvantages, the LB-50 lasted about 30 minutes longer.

    Conclusion

    That’s probably way more words than needed to be written about these batteries.  The TL;DR summary is this:  Zaxcom’s advertised runtimes are pretty close as a best case, but you’d probably be wise to knock an hour off each if you want a realistic average case.  In other words:  Expect 6h from the ZMT4, and 15h from the ZMT4-X.  I’m still shocked at 15h of runtime on a transmitter.  That’s effectively unlimited for normal shoot days.

    I’d say there’s some evidence that the Lectrosonics LB-50 does offer better performance than the much more common Fuji battery.  Whether that extra half an hour is worth paying almost double for is up to you.  I’d guess that for some people it might be:  reliably getting over 6h is the difference between never having to change batteries before lunch and potentially having to scramble for last minute battery changes right before lunch.  If production is paying for batteries as expendibles (which they should be), buying the Lectro batteries will make you a more reliable mixer.

  • A Bluetooth keyboard for the Zaxcom Nova

    Rotary knobs suck for entering text. I got pretty fast at using Zaxcom’s on-screen keyboard on my Nomad (and now, my Nova), but it’s not the same as a real keyboard. I have developed the very specific skill of being able to simultaneously walk quickly and write scene notes or track names on my recorder as we hustle towards our next shot. It is possible to use a keyboard with the Nova (and the Nomad, with an asterisk or two), but I could never figure out how to make it bag-friendly. A keyboard seemed like it would add awkward bulk and weight, and the trade-off never seemed worthwhile: Doing docs, I value mobility and the ability to keep up with the action over most other priorities.

    I started seriously looking at keyboards when I bought my Nova, but even “mini” keyboards built for tablets and phones are too big for a bag. There’s an ergonomic reason for this. A keyboard can only be so small before it stops being possible to type on it with ease, and most mini-keyboards are intended to be an upgrade over the on-screen keyboard of a touch-screen device. There’s not much point in a keyboard that is so too small for your fingers to fit on comfortably — tablet keyboards are already too small. But I’m not trying to improve on a touchscreen keyboard. My baseline is much lower: The rotary-knob keyboard on the Nova means typing each letter takes a second or two. I don’t care about touch typing; I just want to enter a few words here and there without it needing my full attention.

    There’s a small market niche for thumb-keyboards that seems to be aimed at gamers or home theatre devices. Perfect! A lot of these are generic brands that troll the depths of Amazon marketplace and all come from the same factory, but there is one brand that does seem prominent, if that word can be applied to such an obscure niche: Rii. Most of their keyboards seem to be aimed at gamers or home theatres, and they come with lots of unnecessary bells and whistles like track pads and joysticks. But, they have one, very plain, very small model that isn’t even listed in their product index. I give you the Rii 518BT Bluetooth Keyboard.

    The smallest keyboard on the internet.

    This is literally the smallest keyboard I could find on the internet. It is a little under 11cm wide, and it fits in the palm of my hand. More importantly, it could fit on my sound bag without getting in the way. Just one problem. The 518BT Bluetooth Keyboard uses … bluetooth. The Nova needs a custom-built cable and an obscure menu option just to handle USB. Bluetooth? It doesn’t do it.

    Spot the keyboard. This is the level of unobtrusiveness that I was looking for.

    I gave up. Putting a bluetooth device next to my precious receivers was probably a bad idea anyway. For about six months, I put the idea out of my head, until I read about someone else using a wireless keyboard with the Nova. Not in a bag, mind you, but it got me thinking. Most wireless keyboards use 2.4GHz dongles but show up as regular USB devices. Surely I could find a bluetooth dongle that could do the same thing? Surely some obscure Chinese manufacturer would be filling this equally obscure product niche somewhere on AliExpress? No such luck. It doesn’t exist.

    The most frustrating thing is that the technology to do it technically exists. It’s called HID proxy, and it’s part of the bluetooth spec. An optional part. A part that is ignored by pretty much every chip-maker that manufacturers bluetooth chips because it requires extra hardware, and is therefore more expensive to make.

    An aside: Most devices that can plug into a computer provides the bare minimum amount of hardware that is needed to convert some sort of input or output into digital bits. The rest is software. Most of bluetooth is software; the “bluetooth” in a bluetooth dongle is mostly just an antenna and a receiver chip that can turn the raw RF that the antenna picks into bits. The dongle feeds those bits to the operating system, which does the rest of the bluetooth magic in software. If your operating system doesn’t support bluetooth (and the Nova’s operating system definitely does not), most bluetooth dongles don’t actually add bluetooth. It is possible to implement bluetooth in hardware; that’s more or less what the HID proxy part of the bluetooth spec does: It provides a way for a bluetooth dongle to output a USB signal (a very specific subset of USB called HID) instead of a partly-bluetooth stream of bits that needs software to interpret it. The reason why no HID proxy devices exist is because the vast majority of bluetooth dongles are intended to be plugged into devices that do have software that supports bluetooth, so why add hardware to do a job that works perfectly well in software?

    Unfortunately, knowing why an HID proxy dongle doesn’t exist doesn’t get me any closer to making it exist. Or does it? It turns out most of the people interested in an obscure bluetooth capability like HID proxy are hardware developers who want to use bluetooth for their own bits of hardware, hardware that doesn’t have software support for bluetooth. So, when I searched “HID Proxy” looking for a dongle for purchase, what I got was a whole bunch of developers talking about how they were building their own bluetooth dongles. Uh oh. My inner tinkerer was tingling.

    When I say small, I mean small. That bright pink box tucked behind my Nova is a computer.

    Enter the Raspberry Pi. For those who aren’t tinkerers, a Raspberry Pi is a very small, very slow computer. But it’s a computer nonetheless, which means it can run an operating system that supports bluetooth. It turns out, there’s a Raspberry Pi model that includes the necessary hardware for both bluetooth and USB, and, because the Pi is mostly of interest to tinkerers, someone has already written the software I need to connect a bluetooth keyboard to the Pi, and send the keystrokes from the keyboard out to another device via USB. In theory, I just needed to put the pieces together.

    In practice — let’s just say the problem with tinkerers is they never finish tinkering, so nothing is ever quite done. The Pi (specifically, the Raspberry Pi Zero W) has a lot of things going for it. It has bluetooth and USB. It can be powered by its USB port, which means I should be able to plug it in to the Nova without running a separate power cable to my BDS. It consumes as little as 0.4W which is more than I would like just for a keyboard, but not so much that it seriously damages my battery life. And it’s small and light enough to fit in my bag.

    I’ll spare you the painful tinkering details of getting the software up and running. Suffice to say, it worked in the open-source, Linux sense of “worked”, meaning it technically did was it said, but required a bit of troubleshooting and a fair amount of arcane knowledge of how software and Linux work to get it up and running. I have to say, I was pretty impressed when I plugged it into my non-bluetooth capable desktop and was immediately able to start typing on the Rii keyboard.

    Now I needed to plug it into my Nova. In the strange logic that only makes sense to Zaxcom, the Nova has what looks like a USB port, but which outputs an old-fashioned RS422 serial signal. We do things like that in audio; we like running unusual signals through familiar connectors (I’m looking at you, Dante). In an added twist, the Nova can switch the signal that is output through the USB port to use USB signally … but only with a custom cable that swaps a few pins and adds a couple resistors. I didn’t design it.

    One more thing: I own the outboard fader panel for the Nova — the FP7 — which is already plugged into the USB, <ahem> serial port on the Nova. Thankfully, this is a solution, not a problem, because the FP7 has a genuine, honest-to-God USB port on the back that is specifically designed to pass a USB keyboard signal through to the Nova. It probably helps that the FP7 is, in fact, a different flavour of Raspberry Pi under the hood, so the USB port probably comes free with the processor. For those keeping score, that means that the signal chain for connecting the keyboard goes through two separate Raspberry Pis before it gets to the Nova.

    This kit contains two Raspberry Pis.

    Plugging the Pi into the FP7 produced … nothing. Actually, it produced a python exception in the log of the Raspberry Pi, but I’m sparing you those details. I had two issues. One, I didn’t get anything unless the Pi was running its special relay software before I plugged it into the FP7 (and the FP7 also needed to be freshly booted). This meant my plan of powering the Pi from the FP7 wasn’t going to work. Two, most of the keys didn’t work … which I eventually realized was because the Nova acted as though CTRL was permanently pressed, which gave me a grand total of six working hotkeys: CTRL+R, CTRL+S, CTRL+P, CTRL+T, CTRL+V, CTRL+C, corresponding to Record, Stop, Play, Enable Tone, Toggle Slate Mic, Toggle Comms Mic respectively. Those functions already have prominent, dedicated buttons on the Nova, so I wasn’t interested in using my keyboard just for that.

    Thank goodness I like to tinker, because fixing #2 meant firing up a debugger to troubleshoot the relay software and digging into the technical details of the HID spec to find out exactly what data the Pi was sending and what the Nova was expecting to receive. For the record, CTRL-R looks like x01/x00/x15/x00/x00/x00/x00/x00 when the Nova receives it. It turns out, there are two specifications for how a USB keyboard can send keystrokes, the default called “report protocol”, and a much less flexible one called “boot protocol”, which is designed for situations where the bare minimum functionality is needed. Guess which one the Nova uses? I won’t pretend I fully understand the difference, but thankfully full understanding wasn’t needed for me to hack at the code enough to get it working.

    I can’t tell you how gratifying it was to turn on my keyboard and suddenly see my keystrokes coming through. I was unreasonably happy that CAPSLOCK worked as expected; it felt like I’d added a new capability to my mixer. I’m sure a significant part of the gratification was how difficult it had been to actually get working. But I’m also proud of being able to do something that is definitely not supported by Zaxcom: connecting a bluetooth keyboard to the mixer, and perhaps helping ensure my safety by making it so my very specific skill of entering text by rotary knob while walking isn’t something I need to rely on.

    My mixer keyboard mounted with velco to the front of my bag, right where I need it. Small, light, and convenient.

    Time will tell if this is actually a useful addition to my bag. I still haven’t solved the issue of needing the Raspberry Pi to be booted before I plug it in, and that is actually a serious impediment. At the moment, this is the process for turning the keyboard on:

    1. Plug the Raspberry Pi into a USB power supply (which means I need to add this to my BDS (Battery Distribution System) … and I also need to buy / build a BDS, since my bag currently only needs to power three devices (the Nova, the FP7, and a TRXCL5, powered directly from a pair of dual-output battery shoes).
    2. Turn on the keyboard (a toggle switch).
    3. Wait 45-60 seconds for the Pi to boot.
    4. Press keys on the keyboard every 15 seconds to check if the Pi is booted (the light on the keyboard is the only indication of when the Pi is ready).
    5. Plug the Pi into FP7.
    6. Disconnect the Pi from the USB power supply (optional).

    I’m not sure if that process will be too much trouble for the benefit of having the keyboard. I have a feeling I will end up just not bothering a lot of the time. At the moment, I’m fairly sure that fixing it so that the keyboard powers up with the FP7 needs to be done in the FP7 firmware, which is a bit beyond my hacking abilities. Powering up the Pi from the FP7 not only prevents the keyboard from being recognized, it also prevents the FP7 from recognizing a regular keyboard until the FP7 is power cycled, so I think I may be freezing the USB driver in the FP7.

    Another possibility I haven’t explored (because I’m not hopeful) is powering the FP7 from the Raspberry Pi. I noticed this while trying to reboot the FP7 during testing: If I had the Pi powered from the wall while it was plugged in to the FP7, pulling the power on the FP7 didn’t reboot it because the power source would fail over to the Raspberry Pi. Just another quirk of the FP7 also being a Raspberry Pi under the hood.

    I feel like I’ve proven something here. I proved it is possible to use a Bluetooth keyboard with the Nova, and that seems worthwhile, because there are no other suitable keyboards for a sound other than the Rii 518BT. I’m very happy with it. The keyboard itself cost me CAD$20, and I paid CAD$40 for the Pi with its case from someone on Craigslist (this is slightly more than the retail value, but it was cheaper than shipping it). And, now that I have a computer plugged in to my mixer, I’m wondering what else I can do with it? I’ve been thinking for a while that I need an automated card transfer script for amalgamating recordings from all my transmitters with the mirror card on the Nova. Maybe that will be my next project…