Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rad Pro: Power off while USB-powered produces alarm #188

Open
Memorandlum opened this issue Jan 4, 2025 · 2 comments
Open

Rad Pro: Power off while USB-powered produces alarm #188

Memorandlum opened this issue Jan 4, 2025 · 2 comments

Comments

@Memorandlum
Copy link

Memorandlum commented Jan 4, 2025

I powered the FS-5000 via USB and then switched it off by long pressing the PowerSwitch. After 5 minutes an
Alarmsound occured and the red LED blinked(not seeable in the video). I switched on the device, still powered, and the gui-look changed, it looks like a missing overlay/transparency. After I'v interrupted the external power and switched the device off and on, again everything was alright.

WelI, I think the alarm could be initiated from the Tube's watchdog, it might still run whilest the device is externally
powered and switched off.
I attache a Video to clearify the missbehavier and two pictures that shows the precision of the
Radon Graph and the sensitivity of the FS-5000, on the graph you can see visiually the difference of 14nS .

VID_20250104_143251.mp4

IMG_20241231_030655c
IMG_20250101_222206c

@Memorandlum Memorandlum changed the title FS-5000 Radpro 2.03 PowerOff powered TubeWatchdog Alarm Radpro powered PowerOff leads to Alarm Jan 4, 2025
@Memorandlum Memorandlum changed the title Radpro powered PowerOff leads to Alarm Radpro powered PowerOff leads to Alarm and glitch Jan 4, 2025
@Gissio Gissio changed the title Radpro powered PowerOff leads to Alarm and glitch Rad Pro: power off while powered from USB produces alarm and glitch Jan 6, 2025
@Gissio Gissio changed the title Rad Pro: power off while powered from USB produces alarm and glitch Rad Pro: Power off while USB-powered produces alarm Jan 6, 2025
@Gissio
Copy link
Owner

Gissio commented Jan 6, 2025

It seems Rad Pro detects there are no pulses as the HV is turned off, and incorrectly sounds the alarm.

It also seems the display is not correctly initialized.

Thanks for the report and video! Greatly appreciated.

In another issue I asked you the following: on your Bosean FS-5000, do you get to see display glitches as reported here: #163?

@Memorandlum
Copy link
Author

Memorandlum commented Jan 6, 2025

I appreciate and like your work and ambitions a lot, thank you, thank you, thank you, thank you so much for spending
your time and work for all of us!!!! And thank you very much to all people helping with bug-reports, code enhancement, code sharing and so on, thanks a lot!

First time I was a little bit shocked when the alarm occured because I thought it's an over-voltage problem.
(The original Firmware let the display always activated while loading the FS-5000 powered off, I don't like that behavior.)
Then I took a watch and stopped the time till it occures..... exactly 5 minutes, the time for the TubesWatchDog. Well,
your WatchDog works very well and I like the short flashes you sadly can't see on my video, they are like the original count-flashes. :-)

For me, that issue is good to know but less important because disconnecting USB-Power and powercycle the device,
fixes the issue and everything is working properly again.

For now, I think the radpro rev. 2.03 is a very successful revision for the FS-5000:

  • Low Battery consumption, I ran my device 10 days 24/7 and the charge was a little bit under half.
  • It is absolutely stable, I tested a lot
  • You can see 14nS when you just look at the RadGraph, I love it (well whatever a value really means ;-))
  • a fast intuitive handling
  • clear look, less colour = better focus
  • Tube J321, my shortest dead time <63.0 μs / after 3h30m switched on it is <66.0 μs
  • it works
    If you need someone to test things out in deep and support for your work, I'll help, if I can.

#163
I have some experience in electronics and a little bit at programming. I just took a volatile view at your
sourcecodes, it seems to be quite good readable in a normal texteditor, maybe in future I can handle it
and help a bit. For now, the "glitches" in issue #163 looks like an hardware error to me. Well, maybe a memory
damage from static over voltage or just some byte flipping registers or a flash-problem because of a short circuit from
the soldered in pins. I think there are a lot of FNIRSI GC-01 devices, that works correct with your firmware on it???
Maybe you can fix that problem for people with that problem, when you write the memory twice on the fly(not two times behind, doublewrite on the fly the registers) while flashing the firmware. If just few people have that problem, then I don't think it should be a software problem. A lot of possibilities could lead to hardware issues, hard Radioactive beams can damage the data and equipment as well.
Only a suggestion of me, maybe a new module, activatable from the device's config could do the job. A new module,
that creates a checksum of the running firmware and shows it once at a freezing startup-screen. With the resulting
checksum you can proof weather the problem's more on hardware's side, software's side or if the timings needs to be changed. (refreshrate, waitstates...)
Well, sometimes people don't follow the rules, me as well, but working on a PCB you have to follow the rules.
Maybe these devices are buggy out of the box, I don't know but some kind of test, that proofs the
integrity of the programs and/or the device's memory should help to determine the error.
First I think the easiest way to be shure, where to search the issue, is to generate a checksum, that states, that the Software
is correctly present on the device. Maybe it is possible to test the rams integrity with write- and readcycles or
lowering memories refreshrates until errors occure to checkup.

Rules PCB:
0.) if you don't know what you're going to do, just don't do it, all you do, you do at your own risk
1.) wear cotton clothes, non synthetics
2.) ground yourselfe over a higher resistance (some k ohm)
(connect cable at grounded metall like a radiator from central heating or, metal frame, then connect your body on the other
end of the wire with a flexible grounding-ribbon or something else, NEVER get ground from a power outlet and never
touch any electrical driven device while you are grounded because of the possibility of leakage current!!!)
3.) use a potential-free soldering iron, if you don't have one, heat up the solder iron, after that, pull out the power-cable
and just start soldering.
4.) don't touch the PCB
5.) use gold-plated pins, you can get them out of old broken(!) motherboards with its spacers
6.) watchout, your pins never have to touch anything on the other side of the PCB, like the aluminium-shielding of the display
on the backside of the FS-5000!!! (leads to defect device or voltage drop and may lead to fragmented transferred firmware)
6.) switch device off, connect the ST-LINK V2 properly --> the ST-LINKS LED lights on, it´s driven from your device battery
7.) connect USB cable from device to your computer (you should've done that before without geiger-device to install drivers)
8.) press "On-Button" and hold it, then start the script to flash while holding the "On-Button"
9.) after successful flashing, you hear clicks from your geiger. Release the "On-Button" and press it again, to
switch off the device
10.) Disconnect USB, disconnect ST-LINK V2 from device, close device's covering, switch device on to test it
before you lock the cover with its screws
11.) Hopefully you flashed with success and everything's working fine

I flashed my device three times now, out of a vmware-client Debian Bullseye, as rooted user and the flash-scripts made accessable before. It worked perfect for me, no errors, no problems at all and I don't need to obey what the scripts really do, because my Bullseye-Client is just a temporary OS and I am a bit to lazy to check up everything. ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants