m-labs / ionpak Goto Github PK

The firmware can test the system for leakage currents by turning the HV on with the filament off.

Hi
I am thinking of giving it a go to this gauge controller! Looks very promising (and cheap) to me). I work with MBE in an academic research centre. Do you have some estimation for the time it takes to solder all the components?

Looking at the software folder, it seems to me that the "gauge_settings.html" file is missing. Isn't it?

Great job you have done!

same smoltcp bug as in ARTIQ.

See this example driver and transcribe into Rust: https://www.oryx-embedded.com/doc/tm4c129x__eth_8c_source.html

To check if MCU is alive during production tests.

The cortex-m code that enables the FPU is incorrect, but fixing it (sbourdeauducq/cortex-m@cc21af2) does not seem to help.

My understanding is that an ionization gague current is typically measured in μA or below, so a current of over 1mA indicates a fault condition and the device should be shut down. The only possible exception is at power-up, when parasitic capacitance needs to be charged.

More importantly, this provides a critical safety feature: by enforcing a 1mA current limit, the hazard of electric shock is significantly reduced, though by no means eliminated.

The limit should be enforced entirely in hardware.

Needs a few thousand steps instead of the current 160, the more the better.

For security reasons, X-Content-Type-Options: nosniff should be set in HTTP responses.

This is a trivial patch, assuming that there is enough space in the output buffer.

It looks like the currently posted code is an old version, corresponding to the Rev 1 hardware, since the code mentions three FBI range settings. It also looks like it has some values overridden with hardcoded ones, such as the fv_pwm_duty on line 100-101 in loop_cathode.rs.

Is it possible to get the latest code?

Hi,
I hope I am asking my questions in the right place here.
I am considering using the controller for my ion gauges. Before actually building the controller I would like to know the status of the firmware so that I can estimate how much time I would need to implement the features I need. I am new to rust so I might have overlooked something, so please correct me if I am wrong.
It looks to me like:

• the settings for the gauge and the current/pressure conversion are hardcoded
• the measurement starts immediately after initialisation and more importantly cannot be stopped on demand

I have another question for those already running an ionpak:
The collector current is averaged 64x by the ADC and another 512x by the firmware. Is so much averaging really neccessary, does the readout fluctuate that much?
Background of this question: Ideally I would like to control valves and pumps based on the readings of the ionpak. For some cases a 100ms reaction time would be too slow.

Thanks a lot
Lukas

According to @whitequark: The core isn't running fast enough for 32 MHz ADC clock, should go away with the PWM reclocking/resolution increase (#3).