Varying bias settings for the same user friendly settings

25 views
Skip to first unread message

Gokul B Nair

unread,
Jan 25, 2024, 2:00:52 AM1/25/24
to jaer-users
Hi,
I just wanted to understand an observation on two sets of recordings I obtained from jAER:
  1. 1. Start jAER and observe the data.
  2. 2. Without closing jAER, change Pixel Bandwidth, then bring it back to default and observe the data.
The event stream is observed to be more dense in case 2 than in case 1. Event rate was observed to be double in case 2 compared to case 1. The bias settings were 95.0p coarse value and 5.9p physical value in case 1; and 11.9p coarse value and 5.9p physical value in case 2.
Are the two cases above two different bias settings with an expected difference in the behavior of the event stream? Is one user friendly setting expected to show the above variations in biases and output?

Tobi Delbruck (UZH-ETH)

unread,
Jan 26, 2024, 11:11:05 AM1/26/24
to jaer-...@googlegroups.com
Good observation!

It's possible there is a bug in setting the coarse and fine values from
the slider. I will check it.  There is a heuristic algorithm that
selects coarse and fine values given a target current and it ended up
with different values when going back to default in your case. But it's
not surprising that the actual currents differ, since the bias generator
is definitely not ideal. I'm surprised a bit at the factor of 2 in noise
events. Was the lid on lens?  And no movement?


Gokul B Nair

unread,
Jan 27, 2024, 5:17:39 AM1/27/24
to jaer-users
The aperture was closed to a good extent to mimic dim conditions. The camera is affixed for the screenshots attached. But the above observations were observed in recordings where the camera is moving too. 
For the same bias current that can be set with multiple coarse and fine adjustments, is there any way to determine which of them would lead to lesser or higher event rates?
Screenshot from 2024-01-24 19-22-52.png
Screenshot from 2024-01-24 19-22-45.png

Tobi Delbruck (UZH-ETH)

unread,
Jan 27, 2024, 6:46:28 AM1/27/24
to jaer-...@googlegroups.com
The same reported bias current may not be actually the same physical
current. I'm still surprised that you see a factor 2 difference with
same reported current, but it's possible that that combination of course
and fine splitter offsets results in that mismatch in pixel bandwidth.
You didn't touch the threshold biases, did you? (diffOn, diffOff, and diff)

Gokul B Nair

unread,
Jan 29, 2024, 12:28:10 AM1/29/24
to jaer-users
For the above observations, I did not touch any other biases or parameters. I did load an XML file with pre-saved settings, but that was at the beginning right after opening jAER. Between the two observations reported above, nothing else was changed. Do you reckon the increase in event rate was so significant because of closed aperture? too much noise? I'll take a look how the above observations compare for an open aperture setting.  

Tobi Delbruck (UZH-ETH)

unread,
Jan 29, 2024, 1:55:35 AM1/29/24
to jaer-...@googlegroups.com
I'll see if I can replicate it this week. Look in

https://github.com/SensorsINI/jaer/blob/master/src/net/sf/jaer/biasgen/coarsefine/AddressedIPotCF.java#L279

That's where the computation of coarse and fine values is done.

```Java

   /** Returns coarse and fine code values the result in current
closest to current. The resulting current will always be larger than
     * the desired current (unless the current is larger than the
maximum possible), i.e. the fine code will be higher or equal to the
     * actual floating point fine code value, i.e. the fine code
     * @param current
     * @return x value is coarse binary value, y value is fine binary value
     */
    public Point computeCoarseFineValueFromCurrent(float current){
        int newCoarseBinaryValue=computeSmallestCoarseBinaryValue(current);
        // fine code is now  round((desired current / coarse current )
* maxFineBitValue)
        int newFineBinaryValue=
(int)Math.round((current/computeCoarseCurrent(newCoarseBinaryValue))*maxFineBitValue);
        return new Point(newCoarseBinaryValue,newFineBinaryValue);
    }

```

Reply all
Reply to author
Forward
0 new messages