Parallel bus decoding on Hameg HMO Scopes

[opticpow]

One for the fellow HMO owners....

I have a HMO724 with the 8 bit logic probe and I want to decode a 8bit parallel clocked bus (the data bus on a Z80), and I'm wondering if it is possible to use one of the analog channels for the clock? I seem to be only able to select the POD channels, and they are obviously all busy with the data.

Thanks,

Wayne.

[atsthng]

I would like to know this too... It is possible to trigger the logic pod channels (using the logic trigger) using one of the analogue channels 1-4, but I have not found how to do a synchronous parallel decode with the parallel bus (does not seem to be possible, only asynchronous decoding)...

[KedasProbe]

thank you for your feedback.

That's right, at this time you can only decode an 8-bit parallel clocked bus with a HO3508 logic probe that is specified as follows: 6-bit for data, 1-bit for clock and 1-bit for CS.

However I've forwarded your email to our R&D department which is now considering how to use the two idle analoge channels for clock and chip select purposes.

Best Regards
Customer Support Team

I was also wondering if the AUX trigger input couldn't be configured as 1 logic channel....

[opticpow]

As I could not find an answer to this question, I logged a case with Hameg. Looks like at the moment, the answer is no 

Dear Mr Ingram

Thank you for your request.

Up to now you can only decode an 8-bit parallel clocked bus with a HO3508 logic probe that is specified as follows: 6-bit for data, 1-bit for clock and 1-bit for CS.

Nevertheless I have forwarded your query to our R&D department which is now considering to use the two idle analoge channels for clock and chip select purposes.

[KedasProbe]

At least support is consistent

[0xdeadbeef]

As a side note, on the 4ch scopes, the trigger input can't be used for CS while this is possible on the 2ch scopes. Not a big issue, but somewhat surprising that 4ch scopes lack features of the 2ch ones.

About support: the next update is said to be released in the 1st quarter of 2013. I hope it fixes/improves several issues I reported in the last months. Unfortunately, they also rejected/ignored some issues and as the R&D guys typically ignore all answers to their initial replies, it sometimes feels a bit like they don't want to discuss issues and suggestions at all.

[KedasProbe]

As a side note, on the 4ch scopes, the trigger input can't be used for CS while this is possible on the 2ch scopes. Not a big issue, but somewhat surprising that 4ch scopes lack features of the 2ch ones.

Are you sure, which bus? I don't see it on my 2ch.

[0xdeadbeef]

CS for SPI. Indeed else the HOO11 option wouldn't make much sense on the 2ch scopes.

http://www.hameg.com/datasheets.0.html?&no_cache=1&L=1&tx_hmdownloads_pi1[mode]=download&tx_hmdownloads_pi1[uid]=5141

Then again, the above datasheet doesn't differentiate between 2ch and 4ch scopes, so for the 4ch scopes, the information is clearly wrong.

[KedasProbe]

Ah, I (still) don't have the software option, If I would buy my scope now I would for sure use this promotion http://blog.hameg.com/?p=70
I did ask the local office recently if they could make a promotion price for the HOO10 though.
I may not get it since I bought it via conrad and not from the local sales office.
Seems If you buy from Hameg you should really do it at the end of the year

Edit:
I don't understand why they would not add a dual use for the trigger input for all scopes to be used as logic channel, even without logic probe you would have an extra channel.

[0xdeadbeef]

Talking of protocol decoders, IMHO the I2C decoding is not implemented optimally, as it seems to be based on clock edges while the protocol defines e.g. that the data can't change in the high period. Which means that the ideal point for sampling data is amidst the high period. Hardware implementations of I2C tend to change the data exactly after the clock goes low and the HMO decoder doesn't like this. If the sample rate is not high enough to have two separate samples for the clock going low and the data line changing its level, it marks the bit as faulty. This means you need a much higher sample rate to decode I2C with an HMO scope than you would normally need. E.g. >20MS/s to decode a 400kHz signal. My cheap ZeroPlus logic analyzer can easily decode the same signal with 1 or 2MS/s.

Unfortunately, the R&D guy didn't seem to share my concerns about this. Or to be more exact, as I reported issues with I2C decoding of a perfectly valid I2C signal, he sent me an (outdated) I2C spec and claimed "my" I2C timing was too critical. However, this was the hardware I2C of an NXP µC and after all NXP is Philips and Philips invented the I2C bus. Besides, the spec doesn't define any timing between falling clock edge and data edge as it just expects the data to be sampled within the clock high phase, not at the falling edge.
Yet, as mentioned before, my answer to his mail was ignored. So it's hard to tell if they at least are aware of that issue internally.

[kripton2035]

yep this promotion is *really* nice ...

Buy any HMO series oscilloscope together with our CAN/LIN option HOO12 until the 31st of December 2012, and you’ll get the HOO10 option plus one logic probe HO3508 free of charge. This is a great opportunity to get a fully equipped HMO oscilloscope for the price of one option.

[KedasProbe]

E.g. >20MS/s to decode a 400kHz signal. My cheap ZeroPlus logic analyzer can easily decode the same signal with 1 or 2MS/s.

If I set a timebase to 20µs/div (8 clock periods) it uses 25MSa/s so that wouldn't be a problem, but yes it is cutting it close and updating the firmware wouldn't be a bad idea.

[opticpow]

yep this promotion is *really* nice ...

Buy any HMO series oscilloscope together with our CAN/LIN option HOO12 until the 31st of December 2012, and you’ll get the HOO10 option plus one logic probe HO3508 free of charge. This is a great opportunity to get a fully equipped HMO oscilloscope for the price of one option.

Kinda sux that I had to pay for those features myself....

[opticpow]

At least support is consistent

I kinda see it as false advertising. They state that it can decode 8bit bus, but when it is clocked (which busses aren't??) 8 bit really means 6 bit data.....Devil is in the details

[kripton2035]

so you need to buy the 2x8=16 bits version of the scope which is quite a lot more expensive ...
and then you really have 8 bits of visible data. thanks hameg.

[KedasProbe]

I kinda see it as false advertising. They state that it can decode 8bit bus, but when it is clocked (which busses aren't??) 8 bit really means 6 bit data.....Devil is in the details

The sheet says parallel 4 bit source (obviously for serial there is no problem)

But I don't see any reason for them not to fully implement the analog channels as logic channels, it's clearly already on the to do list (if they aren't already busy), otherwise they wouldn't have provided this possible (future) solution.
(obviously if they encoder some trouble they may have to cancel it, so they can't tell you for sure they will add it)

[0xdeadbeef]

I think you can't combine the digital and analog channels for any protocol on the HMOs. My understanding is that for one decoder, they all have to be either digital or analog. It sounds like a limitation easy to overcome, but then again you never know how complicated this is on the FPGA level.