project: extending HP3478A functionality

[Miti]

This upgrade of HP3478 looks awesome (I need to do this ). A video showing the new functions would very interesting  .

https://drive.google.com/open?id=179wN6CET8ZQY1wQDYIMmN7-N4oslAw8C   

[agaelema]

The project is using the internal EEPROM of 328P, correct?

I searched by the main.c but I not found, just the .hex. Anyway, if the initialization of the internal EEPROM is a problem the AVR "EEMEN" allocate the variable in the EEPROM section.

Code: [Select]

"unsigned char EEMEM uc_valor = 0x33;"
http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html#ga79a42ec6c6c8bbbe6e34ed57a52aac59

[kirill_ka]

Still doesn't work for me.

It should  Maybe you didn't add W to save parameters in the EEPROM?
I tried it with DC buzzer and it works for me. The only thing, I tested it with the buzzer beeping at start (I was too much hassle to put it inside 3478A and test it there).  Anyway, I re-uploaded r1.2.1, because that debugging beep sneaked in. There were no major changes in 1.2 release so maybe you don't want to waste your time on this...

Beside that, it didn't even respond to SRQ key until I programmed the EEPROM.

Ok, I'll keep an eye on EEPROM addresses used for variables. So they don't change with the updates unless required.

This is what I meant by "EEPROM Autoinit", after every fresh programming or upgrade, make sure it starts with a default EEPROM that works. This way, once the bootloader is programmed and the fuses configured, we don't need to use AVRISP anymore, everything is done through USB.

I did program EEPROM with the bootloader.
The command is

Code: [Select]

avrdude -b 57600 -c arduino -p m328p -P /dev/ttyUSB0 -U eeprom:w:hp3478-ext-dc-buzzer.eepAs I remember, there's a fuse to erase EEPROM before programming the flash. But it shouldn't affect bootloader in any way. I can put some version code in the EEPROM to force initialization if an incompatible version is detected. But I don't think it's needed for now.

[Miti]

All good now.
Thanks Kirill! 

[Miti]

Kirill,

How hard would it be to redefine the pins to your project to match the one here?

https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

How nice would be to be able to simply program the board through USB to have functionality extension or Prologix USB-GPIB interface, as you wish?
I know that your project has some USB-GPIB functionality but it is not compatible with Prologix.
I tried the other way around, to redefine AR488 pins for my board but it doesn't work. The ports are hard coded in AR488.

[kirill_ka]

Miti, the buzzer pin (PB2) is a problem. There's no alternative mapping for the OC1B.
I more like the idea to implement the Prologix command set in hp3478ext. But I need a bit more motivation to do so.
Now I'm slowly advancing with multi tone continuity mode, which may be very useful for reverse engineering and fault finding.

[bitseeker]

Multi-tone continuity as in changing pitch relative to resistance? I like the sound of that (pun somewhat intended).

[Miti]

The idea is great but the buzzer response is not linear so you'll have big variations in the intensity. But you can control the volume as well so it should be doable.
Using an internally driven buzzer woud solve the PWM output restriction.
Adding the Prologix code to your project would be nice, not sure if there's enough memory though and would take a lot of effort.

[kirill_ka]

Multi-tone continuity as in changing pitch relative to resistance? I like the sound of that (pun somewhat intended).

Yes. For now I have a bunch of parameters: thresholds, pwm periods and pulse lengths. After I gather some use case scenarios, I'll try to figure out a more user-friendly configuration.

[kirill_ka]

The idea is great but the buzzer response is not linear so you'll have big variations in the intensity. But you can control the volume as well so it should be doable.

Yes, both pitch and volume are configurable.

Using an internally driven buzzer woud solve the PWM output restriction.

Then there would be no buzzer control 
I don't like the idea of supporting multiple code forks.

[coromonadalix]

Dont want to be rude or start a fight 

But it seems everyone want some this or that,   and Kirill seems to be under some pressure ??

Keep this project simple,   if people are not happy    take a pause ...  take some distance ... slowly you're been pushed away from your original idea,  i consider myself lucky to have shown this project to a friend, he bought a 3478a  and he's happy with it, want to find a second one ...

The added bonus is a gift from a hard work.


The buzzer idea may have been a bad one, and having multiple code fork, will mess up everything,  unless you take no reponsability and put / add some warnings  but it will be a mess in the end

Every one can understand code constraints / code size / and hardware limits too.


Not on eevblog,  but i saw some free designs and codes dissapearing lately because of what can happen when people dont understand  ... push things to a limit.

[Miti]

Coromonadalix,

Thanks for policing my suggestions! Really, that's all they are, suggestions for improvement ... which Kirill asked for in the first page, if you read that page. I'm not pushing him in any direction. He, s a big boy...I guess. These are only suggestions to make an excellent project even better.

Kirill

Do you feel pushed?

[coromonadalix]

Im just saying, all initials idea are fine    sometimes we dont know when to stop asking for more   loll

Were using a meter who's never meant to have thoses functions added / modded etc etc ..  when it was designed

Even myself i would love to add more and more  loll 

I had two meters who had a variable buzzer tone following the read value (s),  boy it was practical,  i could hear the glitches ... 

But we may face  hardware (s) and or softwares constraints very soon    only Krill knows       and surely he will know when to stop ??


Okay i'll stop  loll  i'm kinda repeating myself too    loll

[kirill_ka]

Do you feel pushed?

I don't  At my main job I don't have a direct connection to the users of our product. Even worse, there may be years until my work meets any user at all. So having some feedback is a nice experience to me.
Thank you!

... will know when to stop ??

Who knows?    Yes, the idea is to have fun of working on the project. And I agree, this is kinda fragile. Thanks for reminding, I try to keep things reasonable.
If you know VIM editor, someday it's author set a limit so all the distribution should fit one 1.44" floppy. That limit was broken, I don't think VIM project had gotten worse after that.

[bitseeker]

It's all good!

[kirill_ka]

I've added some features & customisation parameters to the continuity mode a couple of weeks ago. It seems to work fine, but I didn't play with it a lot. So I decided to throw in a new release
https://github.com/KIrill-ka/hp3478ext/releases/tag/r1.3

Here's a short description of the parameters:

Code: [Select]

SETTING COMMAND            DESCRIPTION
Obeep_period<period>       beep tone used in autohold
Obeep_duty<duty>           beep volume used in autohold
Ocont_beep_ta<R-threshold> lower buzzer threshold for continuity mode
Ocont_beep_tb<R-threshold> upper buzzer threshold for continuity mode
Ocont_range<R-range>       Ohms range used in continuity mode
Ocont_thr<R-threshold>     threshold for continuity mode to start displaying the resistance value
Ocont_latch<latch-cycles>  number of measurement cycles to continue buzzing after the measured resistance gone above the cont_thr
Ocont_beep_pa<period>      beep tone for cont_beep_ta point
Ocont_beep_da<period>      beep volume for cont_beep_ta point
Ocont_beep_pb<period>      beep tone for cont_beep_tb point
Ocont_beep_db<period>      beep volume for cont_beep_tb point


VALUE          RANGE     DESCRIPTION
<period>       0-65534   frequency = 16MHz/2/<period>
                         0 means the buzzer is DC-driven
<duty>         0-127     127 means 50% duty cycle
                         0 disables the buzzer
                         for me working values are 5 to 20
<R-threshold>  0-3000    corresponds to the value displayed on the screen in 3-digit mode
<R-range>      0-6       resitance range number-1
                         refer to the HP3478A programming manual
                         the default is 1 = 300 Ohm range
<latch-cycles> 0-100     the minimal number of measurement cycles the buzzing continues
                         one cycle is ~1/75 of second
                         0 means no latch


OVER       CONT         CONT      CONT         
RANGE      THR          TB        TA           0
 |          |            |         |           |
 V          V            V         V           V
 +----------+------------+---------+-----------+
     \             \          \         \
      \             \          \         beeps using beep_da & beep_pa
       \             \          \
        \             \          beeps using values linearly interpolated from beep_pb..beep_pa & beep_db..beep_da
         \             \
          \             beeps using beep_db & beep_pb
           \
            displays "> cont_thr" (the actual effective value of cont_thr is used)


[bitseeker]

In the last part, wouldn't the message for values over CONT THR be "> cont_thr" (greater than cont_thr) instead of "< cont_thr"?

[kirill_ka]

Ah, yes, thanks. Corrected.

[bitseeker]

Sure thing. I haven't yet had a chance to add this to my 3478A, but still following along.

[yo0]

great project!, it is possible/viable  add dB measurements, frequency, and remember  the prefered digits  for example 4 1/2? thats will be great!, by the way  there is any source to buy for the project pcbs already populated like drop in solution? @Miti?

best regards.


Pio

[kirill_ka]

great project!

Thanks!

it is possible/viable  add db measurements,

It should be possible, but what do you mean by the dB?
Is it relative mode in dB? dBuV?  dBm?

frecuency

No. HP3478 can't measure frequency.

, and remember  the prefered digits  for example 4 1/2?

Yes, I was thinking of adding some kind of save state/recall state functions. That would be a lot more complex than just saving one parameter, but it would be more logical and universal solution.

[yo0]

Thanks!, i mean dBm (some fluke dmms are refereced to 600Ω) dont know if hardware is adequated 


Best regards


Pio

[kirill_ka]

Thanks!, i mean dBm (some fluke dmms are refereced to 600Ω) dont know if hardware is adequated 

Sorry for late reply, I didn't notice the post was edited. I don't know if any DMM  would provide a matching low impedance input.
My Amprobe AM-140A allows for multiple impedance references. All of them require an external termination.
I hope you understand that it would be just a mathematical function, not hardware related.

[yo0]

Thanks!, i mean dBm (some fluke dmms are refereced to 600Ω) dont know if hardware is adequated 

Sorry for late reply, I didn't notice the post was edited. I don't know if any DMM  would provide a matching low impedance input.
My Amprobe AM-140A allows for multiple impedance references. All of them require an external termination.
I hope you understand that it would be just a mathematical function, not hardware related.

thank you, now i understand. i was believing was hardware related as i read in fluke 8060a manual.

just for curiosity what are/mean  the characters in diode test?  >3 Volts perhaps?

best regards.


Pio

[kirill_ka]

thank you, now i understand. i was believing was hardware related as i read in fluke 8060a manual.

The fluke 8060a manual says that the base specifications for dB modes are the same as DC Volts/AC Volts.
So I assume it's just a math function.
What are you going to use the dB measurements for?

just for curiosity what are/mean  the characters in diode test?  >3 Volts perhaps?

Yes. 3kOhm range used for the diode test. It gives us precise 1mA test current, ~6V open circuit, ~3V measured diode drop at max. >3V is a bit of a lie, because it will measure slightly above 3V.