Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Rounding of numbers (e.g. Phase1Duration)
Dear Josh (et al.),

Posted this as an issue on GitHub before realizing you might prefer people to write here in the forum instead

I'm playing a bit around with my PulsePal (Gen 2; FW: 2.0.1).

When setting the Phase1Duration manually (by joystick) to 300µs (=0.00030s) and the PulseInterval to 333ms (=0.33300s) in order to obtain 3Hz stimulation, in a burst of 16s - I, instead of the desired 3*16=48 pulses, get 49 pulses. That makes sense, - as there's still room for another pulse.
So I went for the python interface to circumvent this, by writing a loop with a "total number of pulses per burst".

But that introduces some new problems in regards of rounding.
Regardless if I set "myPulsePal.phase1Duration[1] = 0.00030" or "myPulsePal.programOutputChannelParam('phase1Duration', 1, 0.00030)" - the PulsePal reads the Phase1Duration as "0.00025s". And measuring the pulse width on an oscilloscope, the width does seem to be closer to 250µs.

I've also tried approaches with the "decimal.Decimal" module in python. E.g.
Decimal('300')/Decimal('1000000') => with and without either or both float(Phase1Duration) and round(Phase1Duration,6)...

Same result. The Phase1Duration still reads "0.00025s".

If I put the following:
myPulsePal.programOutputChannelParam('phase1Duration', 1, 0.000301) -> that is, 301µs, the PulsePal reads "0.00030s", and the width (measured with an oscilloscope) does appear closer to 300µs.

According to your paper regarding the PulsePal (Sanders and Kepecs, 2014) you restricted the shortest configurable pulse duration to 100µs, which is also seen in that it is not possible to adjust the last precision point in the float (by joystick). But then it shouldn't be a problem with 300µs pulses? So I guess it is something about rounding...

When I get the python script to print the values that I assign to the Phase1Duration or InterPhaseInterval (etc.), it does seem to be the right values.

So... I'm probably missing a simple mistake that I make? Or there might be a bug in how these values a registered / assigned on the Arduino (the cycle/clock frequency...?)

Hope to hear from you how you would suggest I go forward / circumvent this problem :)

Christian Skoven
*bump* Smile

Anyone having any insights to tackle this problem?


Forum Jump: