changing the rigol DS1052E to DS1102E using USB , the dummy guide

[Spank]

Hello,

Thanks a lot for your great effort here!!!
I got yesterday my DS1052e with FW 02.05 SP1 with the Trigger problem.
- I did all of the things on page 1, SW download and install.
- I downloaded the program of shafri. Thanks great prog 
- Than I downloaded the FW from Killerwhalle: 2.05SP1_to_2.04SP1.zip, did the downgrate to 2.04SP1
- Downgreate to 02.02 SP2 with FW from page 1, the patched one
- Hack with Shafri's prog
- Ugrate with FW 02.04.01.02 from d0ss. Checked the trigger problem => all ok. Timebase down to 2ns. Calibrate. Done

Great! Thanks!!!!

[killerwhale]

Here's a file you can use to directly downgrade to 2.02SP2 from any firmware up to, and including, 2.05SP1 (00.02.05.01.00).

[zenith1111]

Here's a file you can use to directly downgrade to 2.02SP2 from any firmware up to, and including, 2.05SP1 (00.02.05.01.00).

Does any one know if the methods used to "crack" the firmware are documented somewhere?

[tdavis80]

spank:  I also just got a new scope yesterday.  It has the latest hardware REV. What version is your hardware?  I have been reading through the posts and only the newer firmware seems to support the newer boards. I am concerned that I might brick my unit if I downgrade for the hack.  Or does the unit start to work again when you reflash to the latest?


update: I did the update procedure.  Everything went well. Only took about 30 mins start to finish.

[zenith1111]

I've just sent a new bug report to rigol:

[darrylp]

I've just sent a new bug report to rigol:

good,  if they release yet another new firmware to fix this,  then we have three of the new headers used on the 2.05 firmware line, should allow us to see whats changing and in what places.

comparing the 2.05_sp1 and the 2.05_sp1_02 file ( fix the trigger problem )  i cant see what / how its changing. i can see some bytes common, but a third firmware might help more.

if you can post it, assuming you get a reply that is.

[torch]

I've just sent a new bug report to rigol:

Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades". 

[zenith1111]

I've just sent a new bug report to rigol:

good,  if they release yet another new firmware to fix this,  then we have three of the new headers used on the 2.05 firmware line, should allow us to see whats changing and in what places.

comparing the 2.05_sp1 and the 2.05_sp1_02 file ( fix the trigger problem )  i cant see what / how its changing. i can see some bytes common, but a third firmware might help more.

if you can post it, assuming you get a reply that is.

I will

[zenith1111]

I've just sent a new bug report to rigol:

Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades". 

I've tested a lot of flash "drives", some of them don't work, even formatted as FAT32, I could replicate the FAT and NTFS problem with a different flash and the printing problem with a different printer, but it still might be just my hardware...

Rigol certainly is trying to stop the upgrades to upper models, they're protecting themselves, but I bet they never sold as many low end scopes in the company's history as they're selling now with all this exposure. And in the DS1102E's price range there is a lot more good manufacturers competing with them. At least I never would've bought a Rigol product it it weren't for Dave's several reviews in EEVblog and all this talk about the hacks.

[Bored@Work]

I've just sent a new bug report to rigol:

Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades". 

What is a little bit surprising is that the don't manage to stop the software-based hacking. They have a new hardware release (HW59, right?). What would have prevented them from going to encrypted firmware and an ID / version chip on the new hardware?

Maybe it is one of those cases where the original development team, those with the real clue, moved on a long time ago, and they just put random "maintenance resources" on the issue. Those "resources" don't know the HW and SW too well, and haven't the means and the authority to change much, so they are just firing shots in the dark with firmware releases.

[zenith1111]

I've just sent a new bug report to rigol:

Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades".  

What is a little bit surprising is that the don't manage to stop the software-based hacking. They have a new hardware release (HW59, right?). What would have prevented them from going to encrypted firmware and an ID / version chip on the new hardware?

Because that would increase the costs of hardware. A TPM or something equivalent costs a lot of money and would not be hacker proof (look at the three major gaming consoles). I bet the amount of money they would make with the slight increase of DS1102E sales would not cover the cost of the advanced security methods. Like I said above, if it wasn't for this they would have sold a lot less DS1052E's and that would certainly not mean a proportional increase in DS1102E sales.

Edit: I thought mine (HW58) was the latest... But anyway, I bet they're just correcting minor HW bugs found in warranty-returned units, let's see what the next revision brings 

[Bored@Work]

Because that would increase the costs of hardware.

Yes, but ...

A TPM or something equivalent costs a lot of money

... you don't need a TPM or such junk. Just a few cent, maybe for a version  number / serial number / ID chip with a crypto authentication. These chips have become so cheap, that printer ink robbersmanufacturers put them in each ink cartridge to prevent usage of generic cartridges in a printer.

If you are looking for some, start with http://www.atmel.com/dyn/resources/prod_documents/doc8663.pdf

and would not be hacker proof (look at the three major gaming consoles).

No, but it raises the bar. Which is what all this security game is about. You have a lock on your door? Specialists, called locksmith can "hack" it. Some criminals can "hack" it. Your friendly neighbor typically can't. So you stick with that lock, because it is "good enough". When it turns out that your friendly neighbor routinely hack that type of lock, you don't do a simple "firmware" upgrade, like trying another lock of the same type. You raise the bar with using something more serious.

I bet the amount of money they would make with the slight increase of DS1102E sales would not cover the cost of the advanced security methods. Like I said above, if it wasn't for this they would have sold a lot less DS1052E's and that would certainly not mean a proportional increase in DS1102E sales.

But then it doesn't make sense for them trying to prevent hacking at all. Either they want to prevent this, then it is astonishing that they don't doe it seriously. Or they don't want to prevent this. In the later case, why are they wasting time with the firmware joke?

[gandalfg8]

I've just sent a new bug report to rigol:

Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades". 

I've tested a lot of flash "drives", some of them don't work, even formatted as FAT32, I could replicate the FAT and NTFS problem with a different flash and the printing problem with a different printer, but it still might be just my hardware...

I'm not in a position to check my scope right now but I wasn't really expecting that FAT and NTFS formatted memory sticks would work with the Rigol scope anyway.

FAT, AKA FAT16, had problems enough with DOS and early Windows systems when hard drive sizes increased above a few hundred megabytes and I didn't think it had been used for anything other than floppy drives for years.

NTFS offers many advantages when used with modern versions of Windows, and I'm prety sure most versions of Linux can handle it these days too, but I can remember at one time, not sure if it still applies, that failure to use the proper "safely remove hardware" option was virtually guaranteed to cause file corruption if NTFS was used on a memory stick.
Since the only option on the scope is just to pull it out, unless the scope is switched off with it in place, it's perhaps not the best option there either.

Given the above it would seem to me that FAT32 is likley to the natural choice and perhaps no great surprise if the other two options were excluded.

[zenith1111]

@BoredAtWork
I agree with most of your statements, but all I'm saying is that the "crypto chips" used in ink cartridges didn't stop the OEM from cracking them open, refill, reset and resell them; when it comes to "raise the bar" to decent levels of security there are massive costs associated, the development time is significantly increased, etc.

What you are suggesting is creating a new model in the middle of this one's life, that is not very good from the business perspective and, after the costs and implications associated with the new development, they would end up with twice the work when it comes to support and bug detection.

If what you said wasn't true the several hardware manufacturers wouldn't spend the amount they do in security, all I'm saying is that right now, in this single case they would probably lose more money than what they would win with a decent security.

Of course they could do it and I could be wrong, but we'll see:)

@gandalfg8
There are lots of USB flash drives up to 2GB that are formatted as FAT by default, I personally never had any issue with it. NTFS can be flagged as "removed unsafely", but if the data was correctly flushed from the buffers there would be no more data loss than on FAT32. I'm pretty sure they didn't implemented NTFS because of it's complexity (I always use FAT in microcontrollers because of that).

[jelmer]

Another successful 'upgrade' of a DS1052E (00.02.05.00.00) to a DS1102E (00.02.04.01.02). Bought mine from DealExtreme at the end of December '10

I used Killerwale's 2.05 SP1 -> 2.02 SP2 and then d0ss's 2.04 SP1 update.

cool,
can someone with a 2.05 (no SP1) system (before trying to downgrade please ) provide me with
1) a screen shot of the version info of the scope (optional, but would be nice)
2) the full version string ( you can use shafry's tool for that. should be somthing like 02.05.00.02 or so

i'll the rewrite/update the guide (need to rewrite it anyway, looks it's getting confusing)

I made some screen shots throughout the update process to update the first post. Enjoy!

[torch]

I've tested a lot of flash "drives", some of them don't work, even formatted as FAT32, I could replicate the FAT and NTFS problem with a different flash and the printing problem with a different printer, but it still might be just my hardware...

That's with the 2.05 firmware your scope came with, right? I'm wondering if this is another piece of evidence that 2.04 SP1 was the last good, stable and bug-free FW release.

but I bet they never sold as many low end scopes in the company's history as they're selling now with all this exposure.

It was a major factor in my decision to purchase a Rigol scope. I was seriously looking at a competitor when I stumbled onto this forum via Google. A new 100mHz scope was outside my snack bracket until I found this thread -- even used ones tend to be more than a new 1052.

Obviously Rigol is making money on the 1052 or they wouldn't be selling it at this price point. The price difference is pure profit, which is what they are trying to protect. The question then is how many customers were prepared to buy the 1102 but bought the 1052 because of the hack? If I had the money and need for a 100mHz scope, I'd doubt I would have found this forum or hack. So my personal opinion is that they are indeed boosting sales and profits overall, by increasing their market share amongst hobbyists.

Maybe they know this and that's why they are just playing with FW instead of making a HW revision? Make it too much bother for a commercial user to change, but still within reach of the hobbyist?

[zenith1111]

That's with the 2.05 firmware your scope came with, right? I'm wondering if this is another piece of evidence that 2.04 SP1 was the last good, stable and bug-free FW release.

Yes, mine came with 00.02.05.01.00, then rigol provided the 00.02.05.01.02. I'm waiting for someone to report if older revisions have this bugs. I think they do, it seems weird that so many bugs would appear later (and the trigger bug did appear and passed QA).

Maybe they know this and that's why they are just playing with FW instead of making a HW revision? Make it too much bother for a commercial user to change, but still within reach of the hobbyist?

My thoughts exactly.

[gandalfg8]

I have RF test facilities up to 1GHz and hope to check the actual amplitude vs frequency response of the scope rather than measure rise times.
I'm planning on doing this by using the scope itself just as an indicator, with a direct coax feed and no probes, so that the measured results rely only the calibration of the signal generator.

With a background in "conventional" analogue and digital design I'd be the first to admit that my understanding of the digital processing that goes on in something like the DS1052E is strictly limited, but there does seem to be something going on under the bonnet of the 1052 that, to me at least, is quite a lot more complicated than I first expected!

Given that my main measurement interest is in analogue RF I set out a few days ago to confirm the bandwidth of my 1052E with 1102E conversion using analogue measurement techniques rather than pulse driven rise time measurements.

Following my initial tests I quickly realised that indicated amplitude, of a periodic waveform at least, both on the scope display and as measured by the scope, varies with both vertical and horizontal settings. Changing the vertical range can indicate a different amplitude for the same signal and having too many cycles per division horizontally adds distortion and also affects amplitude measurements.
Oh well, so far at least I'm learning some limitations as I go along!

Vertical range variation was, hopefully anyway, eliminated by keeping the scope on the same setting and just adjusting the level at the signal generator.
The horizontal setting was a bit more awkward, you can't swing an input frequency over a 150MHz range without adjusting the timebase, but trial and error indicated that adjusting it such that one cycle of the waveform occupied between 1 and 3 divisions gave a reasonably stable result.

Using an attenuator pad on the output of the generator and a transformer based splitter to supply both channels via 50ohm feed through terminations, I was able to remove any scope probes from the measurement chain, so far so good, and at least establish that both scope channels are very closely matched.

What I measured though didn't seem to be very consistent or to make much sense, sometimes I could measure a -3dB point around 110MHz but at others the response seemed to be almost flat up to around 140MHz and then tailing off quite noticeably at 150MHz.
Today, using either one channel or both, I could not persuade it to change from being almost flat to 140MHz.
That lack of consistency certainly concerns me but, for today anyway, it was consistent enough so I just assumed this might be an artefact of using a modern DSO on a repetitive waveform and that the processing was biasing the result.
All very nice but perhaps a bit too good to be true.

Sooooooooo....., and this is where I really starts to lose the plot, I decided that perhaps I should try a rise time measurement after all.
Feeding the scope from a fast rise time impulse generator, originally intended for the calibration of surveillance receivers at frequencies up to 1GHz, has resulted in a very clean displayed pulse with reported rise times of around 2.5ns.
Jitter seems to be swinging this between approx 2.2 and 2.6ns but it still seems to be indicating a bandwidth of around 150MHz!

So what am I supposed to conclude from all this?

I was happy to accept that my analogue bandwidth measurements could be wrong but now my risetime measurements seem to confirm them after all.

Can my 1102E conversion really have 150MHz bandwidth?

Is this suggestion totally unrealistic?

Can anyone explain exactly what's going on here?

Answers on a postcard please..........:-)

[alm]

As long as the sample rate is high enough, I don't see how digital processing would change the frequency response, although the Rigol is not known for very stable, accurate results.

A constant-amplitude sine wave is the fundamental way to measure bandwidth (it's defined as the point where the level first drops below -3dB). Rise time depends on the response curve of the scope, the .35/BW formula is correct for a perfectly Gaussian response (-6dB/octave), I wouldn't count on this being 100% accurate, although the error doesn't tend to be that big (brick-wall response is .4 to .5 / BW if I remember correctly).

Does setting the scope to a different (but constant during the test) vertical setting have any significant effect? I've seen some tests that indicated that the vertical amplifier gain was very non-linear above 30MHz or so, but the results seemed suspect to me, and I don't have the scope myself to verify. I think the attenuator consists of just standard SMT passives on FR4, no custom hybrids like the expensive scopes, so I wouldn't expect great high-frequency performance. I don't think they specified bandwidth measurement very well in their manual, but I would expect it to be measured at a fixed voltage like 1Vp-p. It may not be the same at other attenuator settings.

It sounds like you know your stuff and the test setup is sound, so my initial impression is that your test results are valid, as long as your signal generator is happy with the extra capacitance that the 1Mohm input in parallel with the termination represents. Also watch the bandwidth of those terminators, some are only good to 100-250MHz.

Was the pulse width significantly wider than the rising edge on the scope, i.e. no semi Dirac pulse? To accurately determine the 10% and 90% points, you need the real amplitude, and that's hard to determine without a much faster scope if it's something like a Dirac pulse. The limited bandwidth will also decrease the amplitude.

[saturation]

Thanks a bunch gandalfg8 for doing those performance tests.  Your tests seem to vindicate the performance that others did too, but its good to hear you have the quality of test gear to make me have more faith in the results.  

ADC processing introduces errors on its own.  You'll find many devices with DAC/ADC discussing output 'flatness' through a frequency range.  This error is suggested in the Rigol spec sheet regarding DC accuracy on vertical amp as worse case +/- 4%, not including co-factors such as the sampling method used and the range selected.  Taken into account, its more like < = +/- 5%.

Solution: to reduce it to its minimum, calibrate the Rigol just before testing. The variation you had from first measure to next could reflect ambient conditions.  BTW, did you warm the unit up before testing?

Given the scope has a claimed realtime sampling rate of 1Gs/s and equivalent rate of 25 Gs/s, shows that it performs well within its Nyquist frequency well.

When you say amplitude, does it actually measure differently given the scale?  Is the difference large or is the error within 5% spec?   You may not sweep frequency and hope to hold the image on screen stable.  It may need to reacquire and analyze it.

Solution: To solve vertical and horizontal issues let the Rigol do it via 'auto' then and check both automatic amplitude [ voltage] and frequency readout.

I do think you have a 150MHz scope, but I'm not sure how reliable it is made to operate in that region.  Rigol doesn't have a 150Mhz version of this model scope.  The higher frequency versions are a different model number and have higher sampling rates, 2Gs/s, the 1000CA series.  At least you know it good past 100MHz.  The bandwidth limits reflect the input analog amps, but the ADC sampling rate remains unchanged, and then there's the memory length.  You can try optimizing Rigols' "Acquire options" to overcome some of the test limits you noticed to see if it improves the amplitude variations, so this is an open area of experimentation.

When trying to decide what to apply this scope to, modded or unmodded, given the sampling rate is fixed, the worse case is 250Ms/s on dual channel, real time sampling, long record length.  It suggests, then that even if the hack extends the input bandwidth to 100 or 150 MHz, the aliasing errors caused by the sampling rate, not to mention its memory length, ultimately rate limits its performance.  You can stretch it, but at 50 MHz its unquestionably at its best.  To 100 MHz, use only a single channel to minimize aliasing.  To 150 MHz, you're still within the range of the Nyquist frequency, with higher aliasing error probability.

For repetitive waveforms its another story, the 100MHz Rigol claims 25Gs/s equivalent time sampling, you can sample frequencies to 2.5 GHz.  The 1052E is listed at 10Gs/s for frequencies to 1GHz.

With a background in "conventional" analogue and digital design I'd be the first to admit that my understanding of the digital processing that goes on in something like the DS1052E is strictly limited, but there does seem to be something going on under the bonnet of the 1052 that, to me at least, is quite a lot more complicated than I first expected!

Given that my main measurement interest is in analogue RF I set out a few days ago to confirm the bandwidth of my 1052E with 1102E conversion using analogue measurement techniques rather than pulse driven rise time measurements.

Following my initial tests I quickly realised that indicated amplitude, of a periodic waveform at least, both on the scope display and as measured by the scope, varies with both vertical and horizontal settings. Changing the vertical range can indicate a different amplitude for the same signal and having too many cycles per division horizontally adds distortion and also affects amplitude measurements.
Oh well, so far at least I'm learning some limitations as I go along!

Vertical range variation was, hopefully anyway, eliminated by keeping the scope on the same setting and just adjusting the level at the signal generator.
The horizontal setting was a bit more awkward, you can't swing an input frequency over a 150MHz range without adjusting the timebase, but trial and error indicated that adjusting it such that one cycle of the waveform occupied between 1 and 3 divisions gave a reasonably stable result.

Using an attenuator pad on the output of the generator and a transformer based splitter to supply both channels via 50ohm feed through terminations, I was able to remove any scope probes from the measurement chain, so far so good, and at least establish that both scope channels are very closely matched.

What I measured though didn't seem to be very consistent or to make much sense, sometimes I could measure a -3dB point around 110MHz but at others the response seemed to be almost flat up to around 140MHz and then tailing off quite noticeably at 150MHz.
Today, using either one channel or both, I could not persuade it to change from being almost flat to 140MHz.
That lack of consistency certainly concerns me but, for today anyway, it was consistent enough so I just assumed this might be an artefact of using a modern DSO on a repetitive waveform and that the processing was biasing the result.
All very nice but perhaps a bit too good to be true.

Sooooooooo....., and this is where I really starts to lose the plot, I decided that perhaps I should try a rise time measurement after all.
Feeding the scope from a fast rise time impulse generator, originally intended for the calibration of surveillance receivers at frequencies up to 1GHz, has resulted in a very clean displayed pulse with reported rise times of around 2.5ns.
Jitter seems to be swinging this between approx 2.2 and 2.6ns but it still seems to be indicating a bandwidth of around 150MHz!

So what am I supposed to conclude from all this?

I was happy to accept that my analogue bandwidth measurements could be wrong but now my risetime measurements seem to confirm them after all.

Can my 1102E conversion really have 150MHz bandwidth?

Is this suggestion totally unrealistic?

Can anyone explain exactly what's going on here?

Answers on a postcard please..........:-)

[boeserbaer]

Hi,  Just bought the 1052E.  Successfully upgraded (arrived with 2.04sp1 firmware) using the guide, and Shafri's windows updater (https://www.eevblog.com/forum/index.php?topic=553.msg19727).  For what it might matter to others, I ran the windows updater under vmware on my imac.  I was nervous about bricking my scope, but coming from a Tek 7904, the 50Mhz bandpass was not acceptable.   With the firmware set to ds1102, I am getting 3.2ns rise time at the probe tip out of a NC7WZ logic part!  If it only had 4 channels or the logic analyzer.  However for $399 I am really happy.

Thanks to all of you.

[mindThomas]

I just recieved my DS1052E today from DealExtreme. It is working fine and looks good.
It came with 00.02.05 SP1, and I haven't tried hacking it yet. But I have still managed to fuck it up, so everytime I turn it on, it shows the splash screen, and afterwards it crashes.
The problem started when I switched the Trigger Slope to the arrows going both ways (both high-to-low and low-to-high triggering) - it crashed just when I had selected that.
Though I've managed to fix the scope again, by disconnecting the source I was measuring on, turn the scope off and on again, and press the Run/Stop button right after the Splash screen disappeared. Then afterwards going into the Trigger menu and changed the Slope back!

Are there anybody in here who would try to do the same thing, and see if the same problem occours? As I said, you can "fix" it, if it happends!
Is it really a bug in 00.02.05?

Best Regards
Thomas Jespersen

[twilliams]

This is a "known" issue with 2.05 and seems to have been resolved by a 2.05 sp2 firmware that I believe was posted here a few days ago after a rigol tech emailed it to a member.

I just recieved my DS1052E today from DealExtreme. It is working fine and looks good.
It came with 00.02.05 SP1, and I haven't tried hacking it yet. But I have still managed to fuck it up, so everytime I turn it on, it shows the splash screen, and afterwards it crashes.
The problem started when I switched the Trigger Slope to the arrows going both ways (both high-to-low and low-to-high triggering) - it crashed just when I had selected that.
Though I've managed to fix the scope again, by disconnecting the source I was measuring on, turn the scope off and on again, and press the Run/Stop button right after the Splash screen disappeared. Then afterwards going into the Trigger menu and changed the Slope back!

Are there anybody in here who would try to do the same thing, and see if the same problem occours? As I said, you can "fix" it, if it happends!
Is it really a bug in 00.02.05?

Best Regards
Thomas Jespersen

[mindThomas]

Hmm, ok
Just checked Rigol's page, and they don't even seem to have the 2.05 for download?
Anyways, if I want to hack the scope, is this then possible with this firmware 2.05 SP1 (I've read in this post that it is possible), and the Hardware revision 58?
And what about upgrading to 2.05 SP2 afterwards?

Thomas

This is a "known" issue with 2.05 and seems to have been resolved by a 2.05 sp2 firmware that I believe was posted here a few days ago after a rigol tech emailed it to a member.

I just recieved my DS1052E today from DealExtreme. It is working fine and looks good.
It came with 00.02.05 SP1, and I haven't tried hacking it yet. But I have still managed to fuck it up, so everytime I turn it on, it shows the splash screen, and afterwards it crashes.
The problem started when I switched the Trigger Slope to the arrows going both ways (both high-to-low and low-to-high triggering) - it crashed just when I had selected that.
Though I've managed to fix the scope again, by disconnecting the source I was measuring on, turn the scope off and on again, and press the Run/Stop button right after the Splash screen disappeared. Then afterwards going into the Trigger menu and changed the Slope back!

Are there anybody in here who would try to do the same thing, and see if the same problem occours? As I said, you can "fix" it, if it happends!
Is it really a bug in 00.02.05?

Best Regards
Thomas Jespersen

[Fraser]

I suggest you downgrade from 2.05SP1 to 2.02SP2, hack the scope to 100MHz and then install 2.04SP1 firmware. Your HW58 is OK for 2.04SP1.

If you straight from 2.05SP1 to 2.05SP2, to fix the bug in SP1, you effectively prevent yourself carrying out the hack as there is no way to step down from 2.05SP2 at the moment. If you really want 2.05SP2 on your scope, do the 100MHz hack first then install 2.05SP2, but I know of no advantage to 2.05SP2 and I recommend 2.04SP1 as that seems very strable and still hackable in the future.