Author Topic: TDS 744A (& friends) firmware reverse engineering  (Read 7710 times)

0 Members and 1 Guest are viewing this topic.

Offline dxl

  • Regular Contributor
  • *
  • Posts: 94
  • Country: de
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #25 on: March 30, 2017, 05:35:06 am »
I'd be happy to get the firmware from a TDS784A (V4.1e) but the Tekfwtool doesn't seem to work for me.
I get this:
Code: [Select]
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\TekFWtool>tekfwtool -r test.bin -b 0x01000000 -l 0x400000
Unable to open device
ibsta = 0x8000 iberr = 0

E:\TekFWtool>

I'm using a Prologix USB to GPIB converter which looks like a serial port to the system. Maybe that's the problem? Does it require an NI GPIB adapter?

Yes, it only supports NI-VISA. I didn't had any other GPIB adapter except a GPIB-USB-HS at that time.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 5027
  • Country: us
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #26 on: March 30, 2017, 07:04:32 am »
Somebody needs to come up with a driver that emulates the NI hardware and allows one of the newer USB based interfaces to work. I built my GPIB adapter out of an Arduino nano clone using code I found online. Total cost less than $10 and most of that was the GPIB cable I cut in half to make the adapter. Works great, but shows up as a serial port.
 

Offline alm

  • Super Contributor
  • ***
  • Posts: 1170
  • Country: 00
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #27 on: March 30, 2017, 07:29:27 am »
NI-VISA supports their current GPIB-USB-HS and GPIB-USB-HS+ adapters. Not just their old stuff. That is partly why there adapters cost $500 instead of $100 (that, and actually conforming to the IEEE 488 specs, so you can drive 15 devices with 20 meters of cable). Generally it is up to the GPIB adapter manufacturer to provide drivers (like VISA and gpib32). For example, Agilent/Keysight provide their own VISA implementation for their own hardware. I am not aware of any VISA implementation that supports for the cheap devices that implement an USB serial port. When Prologix talk about Labview support they usually mean that you can adapt your Labview program to interface with their hardware, not use it as drop-in replacement for a real GPIB adapter.

It may be that one of the knock-off Agilent adapters (have they been updated to the Keysight branding yet?) will work with the Agilent/Keysight software, although I do not condone buying knock-off devices that rely on the manufacturer they copied to provide software. Used NI/Agilent devices are sometimes available on eBay for under $200. Be sure to check which devices are still supported by their current software releases. I would not buy a used Agilent adapter from China given the volume of fake Agilent adapters. You could also get one of the cheap NI PCI or maybe even ISA cards if it is just for dumping the scope (if you have a computer and an OS version that supports them).
 

Offline fenugrec

  • Contributor
  • Posts: 45
  • Country: ca
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #28 on: March 30, 2017, 09:08:47 am »
Somebody needs to come up with a driver that emulates the NI hardware
Haha "somebody" should, indeed - I think the NI API is sufficiently documented to make this possible, but on the other side "someone" needs to abstract out the differences between a variety of different GPIB hardware, else design a new one. An interesting project; I'd be willing to contribute but I will not be providing any initiative for this -  I have too many active projects already sharing the "open source spare time".

Note, there has been some initial work done vaguely in that direction, loosely affiliated with sigrok
http://sigrok.org/wiki/Gpibgrok
but as usual for this type of project, a few people will read a bunch of datasheets, draw up a BOM, rough schematics and maybe a PCB, and that's about where it ends. I know this pattern, I've done the same thing a few times.


Back to firmware --
@Jwalling, do you have the internal service port hooked up too ?
 

Offline Jwalling

  • Supporter
  • ****
  • Posts: 1024
  • Country: us
  • This is work?
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #29 on: March 31, 2017, 04:19:53 am »
Somebody needs to come up with a driver that emulates the NI hardware
Haha "somebody" should, indeed - I think the NI API is sufficiently documented to make this possible, but on the other side "someone" needs to abstract out the differences between a variety of different GPIB hardware, else design a new one. An interesting project; I'd be willing to contribute but I will not be providing any initiative for this -  I have too many active projects already sharing the "open source spare time".

Note, there has been some initial work done vaguely in that direction, loosely affiliated with sigrok
http://sigrok.org/wiki/Gpibgrok
but as usual for this type of project, a few people will read a bunch of datasheets, draw up a BOM, rough schematics and maybe a PCB, and that's about where it ends. I know this pattern, I've done the same thing a few times.


Back to firmware --
@Jwalling, do you have the internal service port hooked up too ?

I did make a console port adapter using the info here and a spare option 13 adapter:
https://forum.tek.com/viewtopic.php?f=568&t=137307&sid=4ff0c574ac18b981c98f0a3077b1d867

(Note that that pinout left power and ground unconnected to the option 13 board for some reason...)

Is that what you mean? Is there a way to dump the firmware through the console port?

Jay

System error. Strike any user to continue.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 5027
  • Country: us
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #30 on: March 31, 2017, 05:24:11 am »
Note, there has been some initial work done vaguely in that direction, loosely affiliated with sigrok
http://sigrok.org/wiki/Gpibgrok
but as usual for this type of project, a few people will read a bunch of datasheets, draw up a BOM, rough schematics and maybe a PCB, and that's about where it ends. I know this pattern, I've done the same thing a few times.

Well we already have all that, the Arduino based open source GPIB interface works just fine from a hardware standpoint. What is needed is a software driver to interface with it. I'm not much of a programmer myself, I'm much better with hardware.
 

Offline fenugrec

  • Contributor
  • Posts: 45
  • Country: ca
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #31 on: April 03, 2017, 10:10:33 am »
Is that what you mean? Is there a way to dump the firmware through the console port?

Mostly -- yes you can dump the firmware through the console port, but it's *painfully* slow, so my goal is to find a matching set of

a) firmware dump (GPIB + tektool )
b) corresponding "symbol table", which can only (to my knowledge) be obtained from the service port with the command "lkup"

Different firmware versions will have different symbol tables so they both really need to be from the same FW version.

The symbol table is essentially a list of names (functions and variables) + their addresses, which is a tremendous help for reverse engineering.
 

Offline snoopy

  • Frequent Contributor
  • **
  • Posts: 507
  • Country: au
    • Analog Precision
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #32 on: April 03, 2017, 10:38:39 am »
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 5027
  • Country: us
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #33 on: April 03, 2017, 10:59:30 am »
It's a lot cheaper to build one, this is what I have http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html

I used an arduino nano clone that cost $2.50 and got a cable for $7.50 that I cut the end off and soldered the wires to the Arduino board. Heatshrink over that and it's done.
 
The following users thanked this post: edavid

Offline smartboy123

  • Contributor
  • Posts: 8
  • Country: cn
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #34 on: April 12, 2017, 10:49:40 am »
Is this something I can do over the GPIB interface?
I don't think so, unfortunately.

I'm slowly dumping small chunks of my firmware through the service port ( ~ 150B/s ! slo-o-ow). I think I might be able to change its speed from 9600bps to something more usable... maybe.

There is an option to do it via GPIB. If you set the Calibration switch to 'unprotected' and power on the scope it will appear dead (nothing on the screen, no sound, etc). But it isn't dead. It spawns a minimalistic bootloader, which listen on GPIB address 29 (IIRC), and that will accept commands via GPIB. The format is binary, so you cannot talk with the usual GPIB commands to it.

This is where my tekfwtool comes into the picture - you can start it on your PC, and it will download a minimal binary to the scope which get's executed and takes care about reading/writing memory.

As mentioned before, tekfwtool is here:

https://stackframe.org/tekfwtool/

It's been a while since i used it the last time, but you propably need:

https://stackframe.org/tekfwtool/tekfwtool.exe and https://stackframe.org/tekfwtool/target.bin

I have a TDS784D with firmware version v7.2e, and I'd like to update it to v7.4e. Using Agilent 82357B USB-GPIB adaptor, I execute followed command using your tools:
tektool -e -b 0x01000000 -l 0x10
tektool -w firmware.bin -b 0x01000000 -l 0x400000
The flash erase and program process is smooth, however, after I protected the firmware and restart my device, it doesn't work any more.

Then I roll back to my original firmware(before I program the firmware, I backup the flash to my PC using your tools), unfortunately it still doesn't work.

Before I damage my device by update firmware, I try the NVRAM read/write using your tools, it work very well, so I decide to program the Flash, then a disaster!

Now I totally no idea about how to recover my device, could you give some suggestion?


 



« Last Edit: April 12, 2017, 11:09:17 am by smartboy123 »
 

Offline smartboy123

  • Contributor
  • Posts: 8
  • Country: cn
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #35 on: April 12, 2017, 11:56:54 am »
I read the flash content, it all 0xFF, 0xFF, so that means I erase the flash correct, however, program fail, maybe my flash chip is not supported by tekfwtool.

Is there any other firmware update method, for example through floppy disk?
 

Offline smartboy123

  • Contributor
  • Posts: 8
  • Country: cn
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #36 on: April 12, 2017, 12:43:19 pm »
In tekfwtool web page, it said "only 28F016SA type flash currently supported, takes about half an hour with my GPIB-USB-A cable".
I checked my flash chip, it's TE28F160S570, can tekfwtool support this flash chip?
I found some information in target.c as followed:
struct flash_descriptor flash_types[] = {
    /* Intel TE28F160S5 */
    {   .manufacturer = 0xb0,
   .device = 0xd0,
   .size = 0x200000,
   .blocksize = 0x200,
   .erase_chip = flash_erase_intel_s5,
   .program_single = flash_program_single_cmd40,
    },{
   /* Intel E28F016SA */
   .manufacturer = 0x89,
   .device = 0xa0,
   .size = 0x200000,
   .blocksize = 0x200,
   .erase_chip = flash_erase_intel_sa,
   .program_single = flash_program_single_cmd40,
   .program_page = flash_program_page_intel_sa,
    }
};

I wonder whether tekfwtool support intel TE28F160 or not?
 

Online capt bullshot

  • Frequent Contributor
  • **
  • Posts: 948
  • Country: de
    • Mostly useless stuff, but nice to have: wunderkis.de
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #37 on: April 12, 2017, 03:48:48 pm »

I have a TDS784D with firmware version v7.2e, and I'd like to update it to v7.4e. Using Agilent 82357B USB-GPIB adaptor, I execute followed command using your tools:
tektool -e -b 0x01000000 -l 0x10
tektool -w firmware.bin -b 0x01000000 -l 0x400000
The flash erase and program process is smooth, however, after I protected the firmware and restart my device, it doesn't work any more.

Then I roll back to my original firmware(before I program the firmware, I backup the flash to my PC using your tools), unfortunately it still doesn't work.

Before I damage my device by update firmware, I try the NVRAM read/write using your tools, it work very well, so I decide to program the Flash, then a disaster!

Now I totally no idea about how to recover my device, could you give some suggestion?

There's some mistake in the documentation of tektool, try:
tektool -p firmware.bin -b 0x01000000 -l 0x400000

-w writes to memory (like the NVRAM)
-p programs the flash memory (writing alone doesn't work)

Safety devices hinder evolution
 

Offline smartboy123

  • Contributor
  • Posts: 8
  • Country: cn
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #38 on: April 12, 2017, 05:10:18 pm »
 :) :) :) :) :) :-+ :-+ :-+ :-+
Using "-p" option, my dead device was updated to newest firmware v7.4e now.
Thank you very much.
 

Offline dxl

  • Regular Contributor
  • *
  • Posts: 94
  • Country: de
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #39 on: April 13, 2017, 08:38:02 pm »
Whoops, looks like i have to update the documentation. But glad to hear that it works for you now and the scope isn't bricked.
 

Offline kc7gr-15

  • Contributor
  • Posts: 19
  • Country: us
    • Blue Feather Technologies
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #40 on: October 03, 2017, 04:11:43 pm »
Time to give this topic a nudge. I've got a TDS784D, and have successfully used the tekfwtool executable to read and archive both my NVRAM settings and my current firmware version (6.something). My thanks for providing such a useful widget!

I'd like to put in the last/latest firmware (7.4e), but I saw a post in this thread to the effect that 7.4e may need a different CPU board. Did anyone ever find out anything more about this?

Also -- The .bin files I downloaded, from the ko4bb.com site, for 7.4e include a bootrom.bin file. In contrast, the other firmware file I found for 7.4e is just a single 4MB file. What address position would one need to use, in the tool, to update the bootrom? (Assuming it even needs it).

Thoughts welcome... Thanks much!


---
Bruce Lane, ARS KC7GR
'Quando Omni Flunkus Moritati' (Red Green)
 

Offline Jwalling

  • Supporter
  • ****
  • Posts: 1024
  • Country: us
  • This is work?
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #41 on: October 03, 2017, 08:48:07 pm »
I'd like to put in the last/latest firmware (7.4e), but I saw a post in this thread to the effect that 7.4e may need a different CPU board. Did anyone ever find out anything more about this?

I would be careful doing this unless there's a way to roll it back. I think I remember reading somewhere that this will require a full calibration of the scope.
Jay

System error. Strike any user to continue.
 

Offline kc7gr-15

  • Contributor
  • Posts: 19
  • Country: us
    • Blue Feather Technologies
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #42 on: October 06, 2017, 03:46:40 am »
Thank you. I did indeed make sure I had a fallback ready, in the form of backup images of both flash and NVRAM, before I started experimenting.

Sadly, it seems to have done me little good. My experiments last night have left me with a bricked scope (thankfully, though, the unprotected mode bootloader still works, so I can continue to try reloading/restoration). However, after doing some before-and-after comparisons of the firmware source file and what's getting programmed into the scope's flash (using tekfwtool's -r function), I find differences where there should not be any.

This tells me that, for some reason, the firmware is getting corrupted as it gets written into flash. This also means any restoration attempt will likely fail until I can locate and correct the problem.

One possibility has occurred to me, and I've left dxl a PM asking for his thoughts on it. My computer/GPIB environment is Windows XP with the NI PCI-GPIB board and drivers. I've been running tekfwtool in a "command window."

No matter what the response from dxl, I'm going to try a pure MS-DOS environment as my next step. I really have nothing to lose at this point. Failing that, I'll try an ISA-based GPIB card. My thinking is the current interface may actually be operating too fast to reliably write to the scope, which could be causing the corruption (I've seen similar things happen with serial port overruns).

I'm not giving up on this, even if I end up having to physically remove and program the flash chips manually or replace the entire CPU board. What I learn, and share with others, will be of value no matter what happens.

Thanks much.
---
Bruce Lane, ARS KC7GR
'Quando Omni Flunkus Moritati' (Red Green)
 

Offline Jwalling

  • Supporter
  • ****
  • Posts: 1024
  • Country: us
  • This is work?
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #43 on: October 06, 2017, 04:21:10 am »
Thank you. I did indeed make sure I had a fallback ready, in the form of backup images of both flash and NVRAM, before I started experimenting.

Sadly, it seems to have done me little good. My experiments last night have left me with a bricked scope (thankfully, though, the unprotected mode bootloader still works, so I can continue to try reloading/restoration). However, after doing some before-and-after comparisons of the firmware source file and what's getting programmed into the scope's flash (using tekfwtool's -r function), I find differences where there should not be any.

This tells me that, for some reason, the firmware is getting corrupted as it gets written into flash. This also means any restoration attempt will likely fail until I can locate and correct the problem.

One possibility has occurred to me, and I've left dxl a PM asking for his thoughts on it. My computer/GPIB environment is Windows XP with the NI PCI-GPIB board and drivers. I've been running tekfwtool in a "command window."

No matter what the response from dxl, I'm going to try a pure MS-DOS environment as my next step. I really have nothing to lose at this point. Failing that, I'll try an ISA-based GPIB card. My thinking is the current interface may actually be operating too fast to reliably write to the scope, which could be causing the corruption (I've seen similar things happen with serial port overruns).

I'm not giving up on this, even if I end up having to physically remove and program the flash chips manually or replace the entire CPU board. What I learn, and share with others, will be of value no matter what happens.

Thanks much.

Ouch, that hurts. After you have a look at the flash chips, that might be a difficult task. You'll need a special adapter for your programmer, can't remember the package name but the pins are very tiny. I have transplanted flash chips from a 700D series into a 684C CPU board, but it wasn't easy. (At least for me.)

Good luck!
Jay

System error. Strike any user to continue.
 

Offline kc7gr-15

  • Contributor
  • Posts: 19
  • Country: us
    • Blue Feather Technologies
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #44 on: October 06, 2017, 07:19:54 am »
Well, we're not to the point of chip-swapping just yet. Even if it comes to that, I'm set up for it (Metcal solder/desolder system, and I just got the micro-fine handpiece and tips for it).

As for the programmer: Also, not a problem. The package type is TSOP (Thin Small-Outline Package), and I have several adapters for the various pin counts. Data I/O did a nice job with the Unisite/Pinsite adapter combo.

No, I still want to try the all-MSDOS system approach. I'm really beginning to think I ran afoul of trying to run the firmware tool under an XP command window, especially since other posts I've read have indicated others in my situation were able to successfully recover their scope from a bricked state (and, as far as I know, they were using MS-DOS).

I'll post further updates as I get them. Keep the peace(es).
---
Bruce Lane, ARS KC7GR
'Quando Omni Flunkus Moritati' (Red Green)
 

Offline kc7gr-15

  • Contributor
  • Posts: 19
  • Country: us
    • Blue Feather Technologies
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #45 on: October 08, 2017, 06:13:02 am »
OK, I need to set things aside and move on (for the moment... I'm not giving up, just taking a break).

I got the tekfwtool -p option to work exactly ONCE. Since the -e option didn't seem to be working (I'd get some bizarre error), I got the bright idea of creating an appropriate-length file filled with hex 00 (maybe I should have used FF) and trying to program it in. It worked... My flash is now a blank slate where the firmware normally is (address 0x1000000, for 4194304 bytes after that), but now the scope won't take any further write attempts using the tool. It acts like it does... The tool runs, and gives the expected screen display, but nothing happens to the flash. The scope remains bricked.

One thing I did discover. The copy of the service manual I have lists the CPU board as part number 679-4172-00. However, the more common CPU board seems to be 679-4349-00 (judging, at least, from what I've seen on Ebay). Perhaps this was a late changeout by Tek...?

Anyway, I've updated the tool's creator (dxl) via PM, so I'll give it a few days and see what he has to say. I'm also going to go see if I have a desolder tip for 4o-pin TSOP's...

Keep the peace(es).
---
Bruce Lane, ARS KC7GR
'Quando Omni Flunkus Moritati' (Red Green)
 

Offline kc7gr-15

  • Contributor
  • Posts: 19
  • Country: us
    • Blue Feather Technologies
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #46 on: October 14, 2017, 06:51:58 pm »
Fellow Tek Tweakers,

The adventure is over! After ending up with a 'bricked' TDS784D, I was able to recover it to full operation this evening with the aid of some very smart people over on the Tektronix forum. For the entire story, see this thread: https://forum.tek.com/viewtopic.php?f=568&t=140017

Just in case that link ceases to work, I'll repeat much of what I mentioned here.

First, the programming tool. I'm sorry to say I had only limited success with tekfwtool. I was able to read my 'scope's guts with it, and make backups of both NVRAM and firmware, but trying to write back to it (at least with a PCI-based GPIB card) resulted in corrupted firmware and a bricked unit.

What did finally work was using the original tool (tektool_0.exe) from the file package mentioned in that thread referenced above (it should be downloadable by anyone... If not, I have it on my public FTP archive), in combination with an ISA-based GPIB card (specifically, a AT-GPIB from NI). In retrospect, I have to wonder if a PCI-based setup simply runs too fast in some way or other...?

Some notes on the O-scopes themselves: It seems there are differences in the version of CPU and Acquisition board used on the TDS7xxD series, and NOT all firmware loads are compatible with them. I would strongly recommend checking both the serial number AND doing an actual visual check of the part number labels on the boards before you even think of messing with firmware updates.

Specifically: Serial numbers LOWER THAN B04xxxx may have CPU board part number 679-4172-00. This board is NOT compatible with anything later than firmware version 6.6e, nor is the acquisition board which it pairs with. It also uses Intel 28F016 FLASH chips.

Serial numbers of B04xxxx and higher will likely have CPU P/N 679-4349-00. This board, and its matching acquisition board, need firmware version 7.4e to work (other versions in the 7.x series may work as well -- That would be a question for Tek support). It uses Intel 28F160 chips, and may require a different version of tektool (or, perhaps, tekfwtool) to support.

There's a couple of other things I learned during the recovery process. First, that seven-segment display on the CPU board can convey quite a bit of information. Under normal conditions, with a 'scope which is booted and running normally, the top and bottom segments (a and d, if I remember correctly) should be alternately flashing at about a 2Hz rate.

When the 'scope is in 'Unprotected' mode, the display will count up to numeric 8 and remain there. Parts of it will likely flicker if you start reading or writing processes with tektool.

When you have a 'scope with a mismatched CPU and Acquisition board (Example: 679-4349-00 CPU paired with a pre-B04xxxx acquisition board), you'll get as far as the 'Digital Phosphor Oscilloscope' splash screen, after which it will blank and the alternating flash on the seven-segment display will freeze with one or the other segments dimly lit. This is the TDS equivalent of a Microsoft 'Blue Screen of Death.'

On using tektool or tekfwtool itself: If the tekfwtool -e or tektool -e commands do not show you a series of strings of zeroes when you execute them, your flash is NOT being erased and the program will likely spit back an error code after about a minute. This is a sign that your GPIB setup may not be optimal, and you should try a different arrangement (in my case, I have every reason to believe the switch from a PCI to an ISA-based card is what did the trick).

Keep experimenting, and post your own results (especially if they differ from mine). Hopefully, between this thread and the one on the Tek forums, anyone else who's struggling with a TDS7xx series will be able to come out of it a winner.  ;D

Now, if you'll excuse me, I just have to put the outer case back on my unit and return it to its spot on the bench. My thanks to all who replied, here and on the Tek forum.

73 de KC7GR
---
Bruce Lane, ARS KC7GR
'Quando Omni Flunkus Moritati' (Red Green)
 
The following users thanked this post: Jwalling

Offline Jwalling

  • Supporter
  • ****
  • Posts: 1024
  • Country: us
  • This is work?
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #47 on: October 14, 2017, 08:54:06 pm »

When you have a 'scope with a mismatched CPU and Acquisition board (Example: 679-4349-00 CPU paired with a pre-B04xxxx acquisition board), you'll get as far as the 'Digital Phosphor Oscilloscope' splash screen, after which it will blank and the alternating flash on the seven-segment display will freeze with one or the other segments dimly lit. This is the TDS equivalent of a Microsoft 'Blue Screen of Death.'


That's not too surprising. I believe that the ACQ boards on prefix B040XXX and higher combined the 4 A/D converters into 1 chip where previously there were 4.

Anyway, good job! :-+ You probably have a few more grey hairs now...
Jay

System error. Strike any user to continue.
 

Offline kc7gr-15

  • Contributor
  • Posts: 19
  • Country: us
    • Blue Feather Technologies
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #48 on: October 15, 2017, 04:59:23 am »
Thanks, Jay. Even if I did gain more gray, it was worth it, especially if I end up helping someone else correct a similar goof.

Next step: Attenuator relay changeout.

Keep the peace(es).
---
Bruce Lane, ARS KC7GR
'Quando Omni Flunkus Moritati' (Red Green)
 

Offline Scratch.HTF

  • Contributor
  • Posts: 38
  • Country: au
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #49 on: October 16, 2017, 07:14:43 pm »
How about emulating the oscilloscope with MAME?
This is one way of finding out how to unlock software options e.g. FFT etc.
If it runs on Linux, there is some hackability in it.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf