EEVblog 121GW Multimeter Issues

[vyruz]

Hi everyone,

I received my 121GW 2 weeks ago and am really happy with it, great job Dave!
It wasn't until this week that I had time to play with it. I decided to test the meter's ultra-low current measuring capabilities, something for which I've relied on my trusty EEVBlog uCurrent gold until now.
Good news: The 121GW can measure mA and uA very well, no need for my uCurrent anymore

But that's not what this post is about.
While comparing measurements of my uCurrent I hooked the uCurrent up to the 121GW, and set the 121GW to the mV measuring setting, and noticed something strange.
While the V setting seems to do fine, the mV setting is giving weird measurements. I couldn't identify another means of generating a reliable sub-10mV source right away, so I only tested with the uCurrent.
I made a video of the whole process since I'm not ruling out at all that I botched something which resulted in this behavior :

I had my bench PSU set to 10V and applied this across a 1.8k resistor. This should give ~5.5mA current, which I also did measure when I had to the 121GW set to V, but when I set it to mV, the results were way off, it was showing ~0.260 mV while I was expecting ~5.550. To my surprise, when dropping the voltage on my bench PSU to 5V (expecting to measure ~2.7mA or ~2.7mV on the uCurrent), the voltage on the 121GW went UP to ~2.000 mV ?!?

Something else which I forgot to record on the video, but perhaps someone else can try:
using the uCurrent, I was measuring an ESP module running at 70mA, with the 121GW set to V the measurement from the uCurrent was 0.0070V, which is correct.
But when I switched the 121GW to mV, the measurement was reading ~7.000mV, so there seems to be a decimal point issue here.

[eV1Te]

But I have measured the logging interval at ln 0 to be 4 Sa/sec, or 250ms, but not 5 Sa/sec, as implied in the manual.
That's important to know, if one makes timed logging of data.

That is interesting, did you check if it was exactly 4 Sa/s in all ranges/modes or does it vary? I believe I read somewhere that it is "as fast as the ADC can sample" and that the speed depends on several factors.
When I look at the display I can see that the sampling numbers do not increment smoothly, perhaps this is only an issue with the update rate of the LCD?

[Dr. Frank]

But I have measured the logging interval at ln 0 to be 4 Sa/sec, or 250ms, but not 5 Sa/sec, as implied in the manual.
That's important to know, if one makes timed logging of data.

That is interesting, did you check if it was exactly 4 Sa/s in all ranges/modes or does it vary? I believe I read somewhere that it is "as fast as the ADC can sample" and that the speed depends on several factors.
When I look at the display I can see that the sampling numbers do not increment smoothly, perhaps this is only an issue with the update rate of the LCD?

I did not check all modes, but the Ohm modes and also DCV is 4Sa/s only.
I timed that by a stop watch, measuring 100 samples.

Also, if you use the BT logging, the rate is 0.5sec/sample only, which is exactly 1/2 of that rate of 250msec.

Frank

[Dr. Frank]

Did you by chance try any of the older ones to see if your meter was stable?   I suspect the pre-production meter will require realignment before I can use it again.  If not, I will try 1.02 (assuming it uses the same tables) and report back.   

It's possible that when the meter is in the calibration mode that they use different routines to sample the data.  Maybe the notch is correct in this mode.  Otherwise, I wonder what their process was to align them.  Maybe they update the firmware again after alignment and that's why they did not catch this. 

Hello Joe,
no I went back to 1-05 only, because I feared exactly these incompatibilities , which you describe, i.e. regarding calibration.. as I have a series device, I won't take any further risk.

The calibration process works differently.. there is a countdown of maybe 5 sec for each constant, so at least the sampling time is much longer.

What I also found out, that external hum noise might create a shift, which gives a constant, but not permanent different reading.

That is visible on the 50M range of the 121GW, which might explain the part time out-of-calibration reading.
I also have seen that effect on my BM869, but that were a few counts of shift only, not several %.

I think, that this a common rectification effect, probably on protection semiconductors.

Frank

[Dr. Frank]

I had an even closer look at the noise suppression of 5M and 50M range.

It's possible to greatly suppress this 50Hz noise on the 5M range by a parallel 100nF MKP capacitor, even with a strong magnetic 50Hz field of a transformer inside a lamp, see picture:
The 'normal' noise can be suppressed so far, that you get an absolute stable reading, only a few counts fluctuation..




The 50MOhm range, though, is absolutely stable, it even shows no static shift by the noise, because the 100nF capacitor makes no difference.

In contrast, my BM869 shows not that kind of noise as in the experiment above, but in both 5M and 50M ranges, a static upwards shift is observed, when the 50Hz magnetic field influences the cables.
This shift can be completely suppressed by adding the 100nF capacitor.


In the schematic  of the 121GW, there are range reference resistors R13 (1.11M) and R29 (10M) and a 27nF capacitor, C30, tied together on one side, and towards the network MUX on the other side.

I assume, that at first, the 50Hz noise filter is not correctly programmed, at least in the 5M range.
Then I assume, that this filtering capacitor C30 is switched on, parallel to the 10M reference resistor, so that even this static shift effect is suppressed.
In the 5M range, I suppose, this C30 is not switched on, in parallel to the 1.11M resistor.

In the lower ranges, either the noise filter, and/or this suppression capacitor might be correctly configured.

The 50 Ohm range is unstable on the last digit, due to another reason, as the 100nF does not change that behavior.

So I propose to UEI, to check the digital filtering, and also propose to switch on the 27nF capacitor in the 5M range, if that is really the method used on the 50M range.

Frank

[Dr. Frank]

Seppy, again a last final erratum:

Page 69, line 7, Resistor:

Replace text for GAIN:

R0~R6: 50000

(Remove 2nd line for R6)

explanation: The gain of the 50 MOhm range also has to be adjusted at full scale, i.e. a 50.000 MOhm standard is needed, instead of 40MOhm.

Frank

[tpw_rules]

So I dug into the firmware and it's interesting. For the 5MΩ range, v1.02 configures an oversampling ratio of 4096 but v1.22 has it configured as 1024. That's the only difference in the chipset configuration. Presumably, they did this to help with autorange speed. You are also correct about C30; 50MΩ (which BTW has an oversampling ratio of 8192 on v1.02 and 16384 on v1.22) has it switched in, but 5MΩ does not. Try changing the byte at 0x1F732 in the v1.22 firmware from 0 to 8 to kick it in on 5MΩ too and see how much that improves things. The byte at 0x17F2A controls oversampling at 5MΩ, changing it from 0x10-0x17 changes the ratio from 256 to 32768 (i.e. 2^(n-8)).

Edit: you can use your favorite hex editor to make these modifications. There is no checksum required. Byte 0x0 is the beginning of the file.

[Dr. Frank]

So I dug into the firmware and it's interesting. For the 5MΩ range, v1.02 configures an oversampling ratio of 4096 but v1.22 has it configured as 1024. That's the only difference in the chipset configuration. Presumably, they did this to help with autorange speed. You are also correct about C30; 50MΩ (which BTW has an oversampling ratio of 8192 on v1.02 and 16384 on v1.22) has it switched in, but 5MΩ does not. Try changing the byte at 0x1F732 in the v1.22 firmware from 0 to 8 to kick it in on 5MΩ too and see how much that improves things. The byte at 0x17F2A controls oversampling at 5MΩ, changing it from 0x10-0x17 changes the ratio from 256 to 32768 (i.e. 2^(n-8)).

Is it possible to tweak the bin file with a HEX editor, and w/o any checksum alignment?

THX Frank

[tpw_rules]

So I dug into the firmware and it's interesting. For the 5MΩ range, v1.02 configures an oversampling ratio of 4096 but v1.22 has it configured as 1024. That's the only difference in the chipset configuration. Presumably, they did this to help with autorange speed. You are also correct about C30; 50MΩ (which BTW has an oversampling ratio of 8192 on v1.02 and 16384 on v1.22) has it switched in, but 5MΩ does not. Try changing the byte at 0x1F732 in the v1.22 firmware from 0 to 8 to kick it in on 5MΩ too and see how much that improves things. The byte at 0x17F2A controls oversampling at 5MΩ, changing it from 0x10-0x17 changes the ratio from 256 to 32768 (i.e. 2^(n-8)).

Is it possible to tweak the bin file with a HEX editor, and w/o any checksum alignment?

THX Frank

Exactly, just change those two with your favorite hex editor. I clarified in the post itself.

[tpw_rules]

Could you also please check version 1.0 as well while I dig out a Hex editor...

I'm sorry but I don't have that binary so I can't look. Please PM me a link or attach it.

If you are good with a hex editor, here is what v1.02's looks like so you can find them in the binary. You can crossreference them with the HY3131 datasheet; each entry is the values for R20-R33, one per range. R2A bits 0-3 are the switches for C30 (bit 3 is the switch to the input); lowest 3 bits of R22 are the oversample ratio.

Edit: yes, that byte is 0x12 to select 1024x oversampling. Valid values are 0x10-0x17 to select oversampling degree; I guess you thought I meant "change 0x10 to 0x17".

[tpw_rules]

I can't find anything obviously different in the ohms measurement logic between v1.00 and v1.02. The chip registers are the same and the software averaging is the same. The only difference I can find is that v1.00 log processing happens in a different place and not as frequently (part of it executes whether logging is enabled or not). Maybe the CPU is less busy and thus contaminating the measurement less. If you like, you can try and patch the 4 bytes in v1.02 at 0x1B672 with 0x00 0x80 0xAF 0xF3 (to disable that bit) but I don't really believe it will help. Maybe I'm missing something.

[joeqsmith]

I compared the section in 1.00 you pointed out as well as it is indeed the same as 1.02.  When I run the two versions they appear different.

I have uploaded the modified 1.22 changing just the two bytes to start.   Just looking at how it behaved, it did not appear to make much if any difference in the 5M range.   Let me collect some data and we can compare the results.

[joeqsmith]

The card is a pain for logging.  I have left the meter apart since starting this little side project.  I don't have long enough finger nails to reach the card and my fingers are too large.  So needle nose pliers.  Not wanting to crush the card, I tend to be very careful when pulling it out.  Today, I dropped it into the meter and it falls behind the cover.      I understand they are not wanting to download the contents of the card using BT like I can with the CEM or Gossen meters.  So logging really will require the B/T to work.   

TPW, it appears that you are at least on the right track.   The first set of data shows the unmodified 1.22 (yellow) dominating all the other data sets.   

The second set is showing the unmodified turned off.   The modified version of 1.22 is purple.   It doesn't appear to be as stable as 1.0, the unknown version or the old December firmware but it's not as noisy as 1.02 was.  From my test setup, I can't explain why the older versions do not have these spikes and appear to have less noise.   Beyond the firmware, about the only environmental change is temperature. 

[tpw_rules]

To be honest I wonder if it's just how the software is structured. In firmwares v1.02 and above, the logging engine captures the current value on the screen every 100ms. In v1.00 and below, the logging engine captures the value on screen whenever it changes. This period I don't know, but it is not a nice round number of milliseconds. In both cases, this captured value is written to SD when the logging interval elapses (every 200ms, 1s, 2s, etc). This might explain the noise in the last count being different between the two, especially on the fastest logging setting.

I've attached v1.00 patched with v1.02's logging method. See if using it gives you the same kind of noise as v1.02.

[joeqsmith]

I had attempted to patch the 1.02 as you suggested with the 4 bytes.  I ran it but sadly when I went to retrieve the data, the file was not created.  Anytime this has happened, the MEM is displayed and the counter is being updated.  I press MEM, stop the logging and turn off the meter to pull the card, but there is no file.  Maybe it's doing some house keeping on the card and I am not giving it enough time before turning off the meter.   

Anyway, I have restarted this test.   Once this is done, I will try the 1.0 version you patched as well.  After I have all of the data, I will post a new set of plots.

Again, thank you for taking the time to help dig into this.   Seems early when I saw you post, you did not yet have a meter.  Is this still the case? 

[tpw_rules]

I had attempted to patch the 1.02 as you suggested with the 4 bytes.  I ran it but sadly when I went to retrieve the data, the file was not created.  Anytime this has happened, the MEM is displayed and the counter is being updated.  I press MEM, stop the logging and turn off the meter to pull the card, but there is no file.  Maybe it's doing some house keeping on the card and I am not giving it enough time before turning off the meter.

Anyway, I have restarted this test.   Once this is done, I will try the 1.0 version you patched as well.  After I have all of the data, I will post a new set of plots.

Yes, that 4 byte patch deliberately breaks SD logging to test if it's interfering with the measurement. I thought you were using Bluetooth to get data out, but I now see your meter can't use Bluetooth. In that case, the patch is worthless. Try the v1.00 patch instead, it has complete logging functionality that's like in v1.02.

Again, thank you for taking the time to help dig into this.   Seems early when I saw you post, you did not yet have a meter.  Is this still the case?

Yes, I have a preproduction unit Dave generously donated and a Kickstarter US unit I purchased. I just don't have the test equipment you have. I will though once I get back to school, but then I'll have less time for fooling with the meter.

[Dr. Frank]

I have noticed, that in FW 1-22 at least, the display content (in 5MOhm range) is different than the data written to the SD card; there is a small offset, and the written data might be more noisy.

In 50MOhm range, the sampling rate on the display is much slower, but at ln 0, data is still written at 4 Sa/sec, obviously producing multiple data logs on one A/D cycle.

BT logging is always slower than SD card logging, 1/2 of the speed.

That I do call: no reliable data logging.

Frank

[tpw_rules]

I spent some time running a few sweeps.  The patch you provided acts very strange.   It appears to log and actually creates the files.  I am testing in the 5Meg range with the same 1.9Meg resistor I have been.  While logging the meter displays 1.9Meg.   I have attached the two files.  At least it appears to be repeatable.

Heh, teaches me to be hand assembling at 10PM. I confused some registers so I think memory got a little corrupted.

However, I did discover something more interesting. In v1.00, the log engine captures the value on the main screen as soon as it updates. In v1.02, the log engine captures the value _for the bargraph_ every 100ms. The value for the bargraph is the value from the ADC after it has been scaled according to the calibration, but before software averaging (8x), smoothing (rolling average of past 10 numbers), and nonlinearity correction (on 5MΩ and 50MΩ). So this noisier value, with a small offset due to nonlinearity, is exactly what you're getting in the log. It's perfectly suitable to scale down to the 25 bargraph segments, but why they're writing it to the log is beyond me. I've attached v1.02 modified to use the screen value. And actually tested it this time...

Regarding sample and logging timing, it's not "as fast as the ADC goes". The ADC speed can be calculated, but it might be different for every mode and range; someone would have to sit down and work it out. The bargraph is updated as soon as the ADC has a new measurement and the screen is updated at a fixed divisor of the ADC speed, to account for averaging. However, the ADC and screen speed is completely unrelated to the logging speed. With an interval greater than 0, the captured value (as described above) is written at the start of the appropriate calendar second (as measured by the RTC). When the interval is 0, the captured value is written every 200ms, but the 5th value in each calendar second will be skipped due to a bug. The net result is four samples per second, but the periods are 3x 200ms and 1x 400ms, instead of 4x 250ms. You can actually see this if you watch the sample number carefully, it will pause every four numbers.

On the other hand, the bluetooth engine simply captures and immediately transmits everything every 250ms. Maybe the bluetooth hardware or the app drops every other packet, resulting in 500ms update speed.

[Caelarius]

I encountered a bug with the logging: After logging temperatures for a long time (21 hrs) I got a file where a number of data points keeps repeating itself.

- Firmware 1.22
- Temperature logging
- Logging interval 145 seconds
- Total logpoints: 520, pretty much 21 hours of logging with that interval
- The logging was started and stopped normally through the mem-button

The first 180 points are normal. The next 60 points, however, keep repeating themselves. So logpoint 181 has got the same value as logpoint 241, 301, etcetera. See the attached file for a graph. The logged csv is available at: https://www.dropbox.com/s/1zq2uf1xgz10y9w/18073002.CSV?dl=0

[tpw_rules]

I encountered a bug with the logging: After logging temperatures for a long time (21 hrs) I got a file where a number of data points keeps repeating itself.

- Firmware 1.22
- Temperature logging
- Logging interval 145 seconds
- Total logpoints: 520, pretty much 21 hours of logging with that interval
- The logging was started and stopped normally through the mem-button

The first 180 points are normal. The next 60 points, however, keep repeating themselves. So logpoint 181 has got the same value as logpoint 241, 301, etcetera. See the attached file for a graph. The logged csv is available at: https://www.dropbox.com/s/1zq2uf1xgz10y9w/18073002.CSV?dl=0

So the logging engine logs points to EEPROM. Every 60 points, it reads all the points from EEPROM and flushes them to SD card. If you power off the meter completely and restart logging, are the points still stuck there? You may have gotten a bad EEPROM for some reason. I can't think of anything else except a bad EEPROM or cosmic rays which would cause this. Maybe it got write protected somehow, but the built in write protection circuitry should have crashed the processor.

[tpw_rules]

Firmware 1.22
I logged my mains voltage for 1 hour plus a few minutes. (MEM button) Logging interval 1 second.
I stopped the logging when the display said 4049 data points.

Issue 1: When reviewing the data on the instrument, it only steps from 1 to 60 and then back to 1 (maybe it should be like that, I don't remember), and the decimal point is in the wrong place. It says 2350.4V for example, not 235.04V.
Issue 2: When loading the data off of the SD-card, the data is only 3990 lines. Not 4049. They're all consecutive. And the decimal point is in the right place.
Issue 3: This is really weird. Look at the attached diagrams. I find the regularity in the right half highly unlikely. Exactly 60 second periods. I must log for longer to see what that looks like.

This seems to be the same issue as Caelarius. Regarding Issue 1, only the last 60 points are available. As mentioned in the previous post, the meter buffers 60 points in EEPROM before writing them to SD card. Only the contents of EEPROM is viewable on-instrument. Regarding the 3990 points, perhaps you didn't give it time to finish flushing? You have to hold the MEM button to turn off logging and wait a few seconds to ensure every sample is saved. Did it tell you the MIN and MAX at the end? It might be a symptom of Issue 3, because I would expect that number to be a multiple of 60. Can you upload the .csv the meter produced?

Issue 3 is the tough one for me. It's stopped writing new points to EEPROM and so whatever was there last is getting saved to SD over and over. Is this behavior present with v1.02? Is the data still stuck in EEPROM? What happens if you start logging fresh? Based on my understanding of the firmware, I don't get what would cause it to stop saving points but continue writing them to the card. The only thing I can think of is that the EEPROM is becoming write protected due to abuse. It's not really designed to stream 18bytes/sec for an hour. They do try every EEPROM write at most 10 times (but don't ever check if the correct value was written!), perhaps to cover up some issues. Maybe I'll have to try and replicate it while the meter is attached to a debugger...

[Caelarius]

So the logging engine logs points to EEPROM. Every 60 points, it reads all the points from EEPROM and flushes them to SD card. If you power off the meter completely and restart logging, are the points still stuck there? You may have gotten a bad EEPROM for some reason. I can't think of anything else except a bad EEPROM or cosmic rays which would cause this. Maybe it got write protected somehow, but the built in write protection circuitry should have crashed the processor.

I just started a new log, I'll have a look tomorrow morning how it looks. Where did you see that the meter logs 60 points to EEPROM before flushing? I couldn't find any reference to that. I'm still cautiously optimistic that this is a software bug rather then a hardware error. Maybe this problem occurs universally with the above parameters and is being caused by the long interval, or the date ticking over to the next day during the measurement, or a combination or maybe something completely else.
I'll also do some logging with a short interval, see where that leaves me.

[tpw_rules]

So the logging engine logs points to EEPROM. Every 60 points, it reads all the points from EEPROM and flushes them to SD card. If you power off the meter completely and restart logging, are the points still stuck there? You may have gotten a bad EEPROM for some reason. I can't think of anything else except a bad EEPROM or cosmic rays which would cause this. Maybe it got write protected somehow, but the built in write protection circuitry should have crashed the processor.

I just started a new log, I'll have a look tomorrow morning how it looks. Where did you see that the meter logs 60 points to EEPROM before flushing? I couldn't find any reference to that. I'm still cautiously optimistic that this is a software bug rather then a hardware error. Maybe this problem occurs universally with the above parameters and is being caused by the long interval, or the date ticking over to the next day during the measurement, or a combination or maybe something completely else.
I'll also do some logging with a short interval, see where that leaves me.

I've done a complete reverse engineering of the v1.02 firmware, which is how I know basically all the information I've posted in this thread. I pored over my disassembly for anything that could explain this bug but I don't see anything. The fact that it's writing bogus data but at a consistent interval is really weird. As you can see, someone else reported something similar. It's 100% a fixable software issue, except for maybe cosmic rays or damage to the EEPROM. Could you reprogram your meter with the v1.02 firmware and see if the issue is still there? I understand it a little more than v1.22. If you can't reproduce the issue, then I can look at what's changed between the versions for clues. Is there any chance whatsoever you own an ARM SWD CMSIS-DAP programmer?

There is a way to test if the EEPROM became write protected. Set up your experiment, start logging, wait however long, then hold the MEM button to turn off logging. Without turning off the meter, turn the dial to your favorite selection and note what mode is shown on the screen. Now, press the MODE key to change modes, and note what mode is now shown. Wait a few seconds, turn the dial to another selection, and then back to your favorite. If the mode shown is the one before you pressed the MODE key, the EEPROM is going into write protection somehow.

[vyruz]

Haven't seen a reply to this and it's being buried under other issues people are posting. Can anyone confirm the behavior I've demonstrated in the video?

Hi everyone,

I received my 121GW 2 weeks ago and am really happy with it, great job Dave!
It wasn't until this week that I had time to play with it. I decided to test the meter's ultra-low current measuring capabilities, something for which I've relied on my trusty EEVBlog uCurrent gold until now.
Good news: The 121GW can measure mA and uA very well, no need for my uCurrent anymore

But that's not what this post is about.
While comparing measurements of my uCurrent I hooked the uCurrent up to the 121GW, and set the 121GW to the mV measuring setting, and noticed something strange.
While the V setting seems to do fine, the mV setting is giving weird measurements. I couldn't identify another means of generating a reliable sub-10mV source right away, so I only tested with the uCurrent.
I made a video of the whole process since I'm not ruling out at all that I botched something which resulted in this behavior :

I had my bench PSU set to 10V and applied this across a 1.8k resistor. This should give ~5.5mA current, which I also did measure when I had to the 121GW set to V, but when I set it to mV, the results were way off, it was showing ~0.260 mV while I was expecting ~5.550. To my surprise, when dropping the voltage on my bench PSU to 5V (expecting to measure ~2.7mA or ~2.7mV on the uCurrent), the voltage on the 121GW went UP to ~2.000 mV ?!?

Something else which I forgot to record on the video, but perhaps someone else can try:
using the uCurrent, I was measuring an ESP module running at 70mA, with the 121GW set to V the measurement from the uCurrent was 0.0070V, which is correct.
But when I switched the 121GW to mV, the measurement was reading ~7.000mV, so there seems to be a decimal point issue here.

[tpw_rules]

TPW,  did you happen to archive the original firmware from the prototype meter? 

Unfortunately, no. I'm not even sure my prototype meter came with prototype firmware, I think it was just v1.01. I honestly can't remember.

The attached video is showing how the patched 1.02 compares with the original firmware's auto-ranging speed.   If you have an older version, if may be worth understanding why there is such a dramatic difference. 

Since I don't have the original firmware, I instead compared v1.02's behavior with v1.22's. As for every problem which faced the firmware engineers, they implemented a function, some timers, a handful of globals, and some conditions which together comprise a poorly programmed and even more poorly thought out "fix".

Here's the behavior in v1.22. It's the same code as v1.02, except the "mode/range change delay" in ohms is now 0, i.e. the meter will perform an autorange on the next sample. This figure was 1 or 2 in v1.02, depending on range. To replace that, there is now an "autorange lock" function called right before the autorange change happens. Rule A: If not in ohms mode, the change is allowed. Rule B: If in ohms mode and changing to a lower range, deny changes for 1 second, then allow all changes. Rule C: If in ohms mode and changing to a higher range, deny the change, then allow one to happen in 1 sample. This leads to some bizarre behavior. If changing from a lower to a higher range, the meter will switch ranges quickly as expected. However, if changing from a higher to a lower range, Rule B above will force the meter to range down as quickly as possible, until either it's at the lowest range or a new ADC measurement arrives. Then it will use each sample to decide to range up, and eventually end up at the desired range. This behavior can easily be demonstrated by starting with open leads and connecting the meter to something like a 100k resistor.

This behavior to me is completely crazy. I don't quite understand the code behind the rules or what purpose they serve, but they are clearly there. I have no idea why they designed it like this. My fix was extremely simple: If the autorange triggered a range change, set the mode/range change delay to 0 in all cases. Maybe that oscillated sometimes, or maybe their method gets 0.001% more accuracy out of the ADC. But based on the above, there's no way to tell why the prototype firmware behaved like it did, and I'm not entirely sure I want to know.