Web-App: Gamma MCA

[rhelectronics]

if you put the Serial.flush() after the Serial.println()?

It does not change the issue.

[NuclearPhoenix]

I test now with a constant number sending like Serial.flush(); Serial.println(2000); delayMicroseconds(25);
and it gives me the solid 2000 line at the spectrum without summing the counts on histogram

Wait so this works now?

[rhelectronics]

its not work with the real data, it works with sending constant number like 2000 at CPS rate

[NuclearPhoenix]

Ok that's very weird. This must be an issue with the random timing of events then, not just the raw count rate. I think this really is somehow a problem with the newlines getting scrambled on their way to the plot. Can you attach two files with the raw serial output of both of your scenarios ("real" and generated), this way I can be sure it's the JS code and not actually the Arduino serial.

Also are you using the Serial.println() from inside an interrupt? This would again reinforce the random timing issue.
And what happens if you add a random time delay between the serial prints with the generated data (say a couple of µs to ms)?

[rhelectronics]

In my case, the pulse interrupt set only busy flag to true
If the code see the busy flag as true, it detach the interrupts and make a work to read pulse amplitude by reading analog pin. So no pulse interrupts are allowed during serial print.

The browser page crashes after several seconds. Maybe it can be useful if you add a maximum received bin filter in case the end line missed? Or add an additional line end characters that can help to ignore erratic data on browser side?

[NuclearPhoenix]

The browser page crashes after several seconds. Maybe it can be useful if you add a maximum received bin filter in case the end line missed? Or add an additional line end characters that can help to ignore erratic data on browser side?

I actually already have two routines in place that 1) throw away too long incoming strings and 2) cap the max number of events in a given time period, but looks like they aren't working as expected.

I'll try to fix these two first and probably update it tomorrow. If the issue still isn't resolved this way, I'm going to add a specific line end char like you suggest, something like a semicolon. Seems more robust this way anyways. Hopefully, that does the trick then.

[rhelectronics]

will wait for you update:)
Yes I saw 1000 cps limit in browser app

[NuclearPhoenix]

here is the example attached,
the spectrum received high values with every update and looks like zoomed out to the bins that never exist in the data. The data is integer 0-4096

Can you do me a favor and export the spectrum and send it to me? Want to check if it's really more channels or some other random NaN error.

[rhelectronics]

Do you need the full CSV spectrum with 4096 channels I have in my hardware?
OR do you need the raw pulse data that I send to your application?

[NuclearPhoenix]

Just the app spectrum with the "export" button in the serial connection tab.

[NuclearPhoenix]

Okay you can test again now, this might (hopefully) be fixed. I just pushed the update to GitHub.

You need to print a semicolon (;) after every energy event, like you suggested.

[rhelectronics]

Thank you! Will test it tomorrow and will send you the requested files, I was away for a while

[NuclearPhoenix]

Thank you! Will test it tomorrow and will send you the requested files, I was away for a while

Does it work for you now?

[rhelectronics]

Sorry still wasn't able to test it! Hope to find time during next 2 weeks, I'll report

[rhelectronics]

So far, your update works much better!

The code I'm using to send the data via serial is:
{Serial.flush(); Serial.print(analogVal); Serial.print(";"); delayMicroseconds(5);

I'll test it and will report if any bug will be detected