Intro:

The protocol used by the UT61e is quite simple, each packet contains 14 bytes. It constantly streams packets as the screen is updated at around 2 packets a second. The 14 bytes are basically a string where the range, digits, function, status are contained.

The serial interface settings are:

19200 baud, odd parity, 7 data bits, 1 stop bit, no handshake.

Describing the protocol:

This snippet shows you how the data is separated, I handle the 14 bytes as a string, which simplifies the process of separating each portion and since this is a low sampling rate application with low priority, it’s not a resource hog.

If ReadSerialPortData( port, @inp, 14 )
			
	If AddElement( *this\sample() )
		*this\sample()\range 		= Asc(Mid(inp,  1))  ; RANGE
		*this\sample()\digits		= Mid( inp, 2,  5 )  ; DIGITS
		*this\sample()\function 	= Asc(Mid(inp,  7 )) ; FUNCTION
		*this\sample()\status		= Asc(Mid(inp,  8 )) ; STATUS
		
		*this\sample()\option[0]	= Asc(Mid(inp,  9 )) ; OPTION 1
		*this\sample()\option[1]	= Asc(Mid(inp, 10 )) ; OPTION 2
		*this\sample()\option[2]	= Asc(Mid(inp, 11 )) ; OPTION 2
	EndIf
			
EndIf

I believe the last two digits are the “end of packet” limiter (CRLF) however I currently cannot test this, I wrote the code a long time ago and I forgot to comment on this slight detail, but as you can see I’ve defined the CRLF contants, so it must be there.

A list of constants:

Here are some constants from my UT61e (unpublished) library…

#FUNCTION_VOLTAGE 		= %0111011
#FUNCTION_AUTO_CURRENT_UA 	= %0111101
#FUNCTION_AUTO_CURRENT_MA 	= %0111111
#FUNCTION_CURRENT_22A		= %0110000
#FUNCTION_CURRENT_MANUAL_A	= %0111001
#FUNCTION_OHMS			= %0110011 
#FUNCTION_CONTINUITY		= %0110101
#FUNCTION_DIODE			= %0110001 
#FUNCTION_FREQUENCY		= %0110010
#FUNCTION_CAPACITANCE		= %0110110
#FUNCTION_TEMPERATURE		= %0110100
#FUNCTION_ADP			= %0111110

#RANGE_ONE			= %0110000 ; Example: 22.000nF
#RANGE_TWO			= %0110001 ; Example: 220.00nF
#RANGE_THREE			= %0110010 ; Example: 2.2000µF
#RANGE_FOUR			= %0110011 ; Example: 22.000µF
#RANGE_FIVE			= %0110100 ; Example: 220.00µF
#RANGE_SIX			= %0110101 ; Example: 2.2000mF
#RANGE_SEVEN			= %0110110 ; Example: 22.000mF	
#RANGE_EIGHT			= %0110111 ; Example: 220.00mF

#DIGIT_0			= %0110000
#DIGIT_1			= %0110001
#DIGIT_2			= %0110010
#DIGIT_3			= %0110011
#DIGIT_4			= %0110100
#DIGIT_5			= %0110101
#DIGIT_6			= %0110110 
#DIGIT_7			= %0110111 
#DIGIT_8			= %0111000
#DIGIT_9			= %0111001

#STATUS_OL			= 1 < < 0
#STATUS_BATT			= 1 << 1
#STATUS_SIGN			= 1 << 2
#STATUS_JUDGE			= 1 << 3

#OPTION1_RMR			= 1 << 0
#OPTION1_REL			= 1 << 1
#OPTION1_MIN			= 1 << 2
#OPTION1_MAX			= 1 << 3

#OPTION2_0			= 1 << 0
#OPTION2_PMIN			= 1 << 1
#OPTION2_PMAX			= 1 << 2
#OPTION2_UL			= 1 << 3

#OPTION3_VAHZ			= 1 << 0
#OPTION3_AUTO			= 1 << 1
#OPTION3_AC			= 1 << 2
#OPTION3_DC			= 1 << 3

#UT_CR				= %0001101
#UT_LF				= %0001010

That's all for now, I currently don't have a serial interface to test with (Ain't got the USB cable either) so I can't finish the library as to post it, but hopefully I'll get it done eventually.

The supplied software by UNI-T is pretty bad and it's Windows only, hence the drive to write my own.

As it is, it should give someone a head-start if they're about to write their own front-end. On the datasheet of the UT61e controller it's all explained in fine detail, but I can't recall the number at the moment.

This whole thing was part of a bigger picture, but I had to give up the concept due to lack of funding.

Alright, enough of this shoulda, coulda, woulda!

Cheers,
Gus

So I recently got a proper Thinkpad and I was wondering how to interface with the accelerometer to obtain data from it. First of all, I had a look around and it seems the ADXL320 is used in most models, it’s a Low Power, 3-Axis ±5 g MEMS Accelerometer manufactured by Analog Devices.

There are, at least on Windows, two possible interfaces. One is through a device manager, the other is directly through a DLL exposed by Lenovo.

I had yet another look around and found a few snippets in C# by Ben Suter. Decided to port the code and give it a go, instead of looking any further. Despite the fact that I had already exported the function names of the DLL (using my good ol’ dllspyr) I just couldn’t bother looking any further. I had to add the z value, since it was originally ignored. Perhaps because previously a mere 2 axis tilt sensor was used?

The other method involves getting a handle of “ShockMgr” with createFile(); setting up by DeviceIoControl(); and then reading through the data. This makes it easier to validate if the “service” is available, because the DLL could be exposed but non functional, for example.

Da codez:

Here’s the preliminary test code, implementing a crude alarm system:

Structure ACCDATA
  status.i
  x.w
  y.w
  z.w
EndStructure

Structure SHOCKSTATUS
  status.i
EndStructure

Enumeration 
  #SHOCKSTATUS_RUNNING
  #SHOCKSTATUS_STOPPED
  #SHOCKSTATUS_AUTOIGNORE
  #SHOCKSTATUS_UNDEFINED
EndEnumeration

Prototype.i pShockproofGetAccelerometerData( *AccData.ACCDATA )
Prototype.i pShockproofGetShockStatus( *ShockStatus.SHOCKSTATUS )


If OpenLibrary(0, "Sensor.dll")
  
  ShockproofGetAccelerometerData.pShockproofGetAccelerometerData = GetFunction(0, "ShockproofGetAccelerometerData")
  ShockproofGetShockStatus.pShockproofGetShockStatus = GetFunction(0, "ShockproofGetShockStatus")
  
  Define.ACCDATA old_data, new_data
  ShockproofGetAccelerometerData( old_data )
  
  Define.i triggered = #False
  Repeat
    
    Delay(200)
    
    ShockproofGetAccelerometerData( new_data )
    
    If Not CompareMemory( old_data, new_data, SizeOf(ACCDATA) ) Or triggered
      triggered = #True
      Beep_(1000, 1000)
    EndIf
    
  ForEver
  
  CloseLibrary(0)
EndIf

The status code is interpreted by another function, which I’m not using at the moment but the author had guessed the threshold values and addressed a name for each, from the known possible states exposed by Lenovo.

Procedure.i convertStatusCode( statusCode.i )
  
  If statusCode >= 0 And statusCode < = 4
    ProcedureReturn #SHOCKSTATUS_RUNNING
  ElseIf statusCode = 8 Or statusCode = 9
    ProcedureReturn #SHOCKSTATUS_STOPPED
  ElseIf statusCode = 13
    ProcedureReturn #SHOCKSTATUS_AUTOIGNORE
  Else
    ProcedureReturn #SHOCKSTATUS_UNDEFINED
  EndIf
  
EndProcedure

What now?

I'm going to clean up the code and start making use of this feature, I mean, why not?

As for a proper alarm, you'd have to manage the mute and volume settings plus instead of comparing against the baseline values you'd have to implement a threshold. I'm aware that they've issued an application that does exactly this, but I'm not a fan of big resident bloatware -- plus where's the fun in that?

Anyway, that's all for now!
Cheers.

This letter is meant to be read by the pertinent executives or anyone in charge of the software/firmware department of the aforementioned companies (Rigol, Owon)…

It is time you take the market by surprise. Open your software. Create the world’s first real production open-source oscilloscope. Let people enhance your work and let yourselves learn from their revisions.

Of course this doesn’t mean you’ll quit developing the main firmware, it only means other people will be able to optimize, enhance and modify the firmware to their liking.

There have been reversals going on and several “hacks” on certain firmware versions, but the need is there. Open it up!

You’re selling the hardware, unlike the primary high-end oscilloscope companies who enjoy selling software and will charge you for every extra feature you want on a scope you’ve already paid full price on. This is the reason why the firmware on your scopes has to be open-sourced as soon as possible, to gain an extra edge on the entry-level market.

The reason Rigol sales sky-rocketed has simply been due to software leaks. Owon and others have not been explored deep enough as of today, so their sales were not increased. This proves the point that software is what drives your sales, not just the quality of your hardware. People want to modify the firmware, add features and remove other features they don’t want/use… Focus on delivering top-notch hardware with an initial firmware and let the clients develop it further on their own or at least allow them to fork and develop their own versions.

While it’s true that due to market segmentation you’ll share the same hardware on at least 3 different models (separated by bandwidth and other features, locked by software) — By having an open-source scope, you’ll only need to deal with one version targeted to everyone, at a fair price. The segmented model is outdated and the only reason you’ve been using it is because Tektronix, Lecroy and others still use it.

Sure, on some instances it works, but Rigol, Owon, etc. are dealing mostly with entry level equipment and thus, money is an object to your clients — Hobbyists and students alike.

For example, due to the firmware “hacks” on the Rigol Ds1052e, more 50MHz units were sold than 100MHz versions will ever be sold, proving segmentation becomes pointless when software is compromised and still, doesn’t hurt sales — to the contrary, it multiplies them.

I cannot stress enough how important this is for both parties. If you are unsure, just release the sources for your flagship model and see how it goes, you’ll be surprised by the feedback and rapid increase in sales.

Be smart: adapt, be the first company to do it and you won’t regret it. There’s no reason why scopes can’t or shouldn’t be open-sourced like some cell-phones and other platforms have been…

Hopefully we’ll see eye to eye on this one.

Best of luck,
Gus

Thanks to Jameco one of my projects is currently being offered as a kit at their great site. It was also featured at their home-page!

About the kit:

The circuit is a variable load with the possibility of using an external voltage to control the load. There’s a lot of flexibility in the design, you can actually use the spare OpAmp (which has a break-out) to suit your own needs. Being able to use an external voltage means you can easily control the load with a third-party circuit, for instance you could have a micro-controller providing step functions, pulses, etc.

This means you can test power supplies and other circuits with ease and flexibility.

In technical terms…

The circuit is actually a current sink and it’s comprised of an error amplifier implemented through a single OpAmp. The shunt is on the low side and we simply use a MOSFET as the current pass device.

You could also turn the kit into a current source to charge up cells and batteries or to measure small resistances (milli-ohms). But the main focus is on having a variable load for your projects.

Being able to make kits that actually explain you why and how things work is a lot harder than I would’ve thought, but hopefully I’ll get better at explaining things as I work on new and exciting kits.

I must thank those who sent me their input with regard to the kit and pointed out the grey areas as well as the mistakes on the PCB / instructions. I really appreciate it!

A note on receiving extra components: Jameco already has pre-packaged bundles and it turns out it’s cheaper to send out 10x resistors in cases where only 1 or 2 are required, so don’t worry if you end up with a lot of spare “nuts and bolts”!.

 In case you missed it, click here to view the kit.

To wrap it up, I encourage you to start publishing your projects as kits at the Jameco site, so others can learn from your circuits and everyone can benefit.
Cheers,
Gus

A Sunday wouldn’t be complete without it’s quote of nostalgia!

That’s when the Z80 comes in, but alas it displayed no signs of life… A quick check with the DMM showed an open conductor on the coax output, so I scrambled for another cable, didn’t have one so I put something together for testing purposes (RF losses didn’t matter at this point) … Still no signs of life, is it dead?

We opened up the power brick, there are 3 screws underneath the rubber feet. Caps seem to be decaying – a bit dry – but they still have a respectable capacitance. I noticed there’s no suppression for high frequencies though but that’s a fix for later. The bridge rectifier tested OK, the transformer was OK, voltage and ripple were OK under load. Time to close it up and discard this as the primary fault.

It’s all down to the unit itself now, a few screws out and the lid pops up, pull-out the keyboard ribbon cable on the mainboard and you’ve got full access to the top of the board now!

This Timex had a custom joystick “expansion” board installed at one time… Notice the gold permanent marker used to hide the IC numbers, weasels…

First things first, I probed the 5v linear regulator. Some surface oxide at first prevented me from getting a good reading, this is common in such old equipment — Make sure you use sharp probes! — On a second test, with good probes, I got a reading and it was up to spec, back to fault-finding mode!

Probed for CLK at the main processor, I got a fairly stable frequency (although it was jittering quite a bit) — So the unit is alive, we just don’t have any video…

Since I didn’t have a RCA cable to test the non RF output with — Which was fitted in case you bought the special monitor that went with the Spectrum. I couldn’t test it this way.

Pointing out at the culprit…

With the RF connected to an old TV, all we got was interference (seems to be putting out a broad spectrum, lot’s of noise throughout the band) but no video at all. So all eyes went to the RF output box, And right out of the gate I noticed a cold joint on the output connector, where the series resistor goes… Bingo!

This was most likely caused by mechanical stress due to lack of physical decoupling of the parts.

But, still no video. Now all I got was a black screen, I wonder what’s wrong with it… A closer look revealed an inductor had been also disconnected at the output, parallel to the series resistor… That’s it!

Now the z80 is alive once again!

 

Man… those games really did suck heaps…

 

Sorry, no action shots at this moment, we were too busy fiddling with the audio level on the laptop to get the roms to load (they loaded!)

However, here are a few extra pics:

That’s all for now!