Hi experts,
Im pretty stuck at around 50Hz when i try burst frames (in RAM), pause to dump to SD card and then burst again:
Starting burst 0 at 20131014_202024…
Saved burst 0: 150 frames @ 49.94 FPS
Starting burst 1 at 20131014_202028…
Saved burst 1: 151 frames @ 50.26 FPS
Starting burst 2 at 20131014_202031…
Saved burst 2: 152 frames @ 50.56 FPS
Do you have method in the pipeline to increase this og even go more towards the real capabilites of the sensor?
Hi, what do you want to do? You cannot record to the SD card at the speed the sensor sends images. This isn’t the design.
Also, while not yet documented and generally released, we have event mode working now, some customers are pulling example scripts and installing the latest dev mode where you can then access all the raw events from the sensor in an ndarray. Are you interested in this over histogram mode?
With 1024 sized event buffers you get 2000+ event buffer returns per second on the RT1062. That said, it’s not necessarily possible to process them at this rate…
Essentially I want to maximize the framerate that can be stored in e.g. RAM (hopefully more than 50ms if e.g. 200Hz ish could be obtained, aiming for 500ms @200Hz but so far no luck). Then stop the capture to store that batch/burst period (for later post processing). Then restart to do another batch/burst period. This should continue until the loop is stopped.
In post processing I stack the batches together to increas signal instead of having a continues stream.
My next step is to fit my post processing pipe line with the potential event buffer. But I have not yet matured the methods for that part. Also I essentially wanted to be sure that it would be an official part of the firmware.
Okay, it will be better to do this with the event mode. Data is far more compact. Do this… use Tools→Install Latest Dev firmware to install the latest firmware for the RT1062. Then, you can run any example here: openmv/scripts/examples/01-Camera/03-Event-Cameras/02-Genx320 at master · openmv/openmv · GitHub
See this deep buffer example: openmv/scripts/examples/01-Camera/03-Event-Cameras/02-Genx320/genx320_event_mode_deep_buffer.py at master · openmv/openmv · GitHub
We support up to 65536 deep event buffers. This is like multiple seconds of events, we could go higher, but, you should be covered by this depth.
I will give it go tomorrow in the afternoon (CET). Thanks 
Is the latest firmware for RT1062 called RT1060?
Just install it using the IDE: Tools→Install Latest Dev Firmware.
Ohh. My mistake. It seemed grayed out at the moment.
It is indeed a fantastic upgrade.
I now have set the following:
# ---------------- Configuration ----------------
EVT_RES = 1024 # Events per read
CAPTURE_SECONDS = 5 # How long per recording
SAVE_PATH = "/sd/recordings"
MAX_EVENTS = 500_000 # Max events kept in RAM
BRIGHTNESS = 128
CONTRAST = 16
DRAW_PREVIEW = False # Turn off for speed
DUMP_BINARY = True
FPS_REPORT_INT = 5.0 # seconds
# ------------------------------------------------
But I am not quite sure that I am getting the full potential.
while True:
clock.tick()
count = csi0.ioctl(csi.IOCTL_GENX320_READ_EVENTS, events)
if count <= 0:
continue
# Write into preallocated buffer (no concatenate)
end_idx = write_idx + count
if end_idx >= MAX_EVENTS:
end_idx = MAX_EVENTS
print("Buffer full before time limit")
count = end_idx - write_idx
accumulated[write_idx:end_idx, :] = events[:count, :]
write_idx = end_idx
event_total += count
# optional fast preview
if DRAW_PREVIEW:
img.draw_event_histogram(events[:count], clear=True,
brightness=BRIGHTNESS, contrast=CONTRAST)
img.flush()
# FPS print
now = time.ticks_us()
if time.ticks_diff(now, last_report) >= int(FPS_REPORT_INT * 1_000_000):
last_report = now
curret_fps = clock.fps()
print("Loop FPS:", curret_fps, "events total:", event_total)
# Check end of recording
if time.ticks_diff(now, capture_start) >= CAPTURE_SECONDS * 1_000_000 or write_idx >= MAX_EVENTS:
duration_s = time.ticks_diff(now, capture_start) / 1e6
print(f"\n⏸ End of capture {file_index}: {event_total} events over {duration_s:.2f}s")
It seems to hover around mid 70 fps:
GENX320 fast capture started
Loop FPS: 76.92308 events total: 261659
End of capture 0: 261659 events over 5.01s
Saved 261659 events to /sd/recordings/rec_20131014_202128_000.bin
Next capture started
Loop FPS: 74.07407 events total: 70773
End of capture 1: 74927 events over 5.01s
Saved 74927 events to /sd/recordings/rec_20131014_202133_001.bin
Next capture started
Loop FPS: 73.17073 events total: 68521
End of capture 2: 75110 events over 5.01s
Saved 75110 events to /sd/recordings/rec_20131014_202138_002.bin
Next capture started
Loop FPS: 72.72727 events total: 64484
Any suggestions to hit like 200Hz+ sample rate relatively stable? Or will it always be control of the event stream?
I also observe quite a lot of speckle noise. Do you have any good examples to effectively remove this with this type of sensor?
Hi, the FPS number doesn’t mean anything in event mode, that’s just the time the loop takes to run per event buffer period. Shrink the size of the event buffers you are grabbing per time and the FPS will go up.
Also…
accumulated[write_idx:end_idx, :] = events[:count, :]
Is not a free operation. The 65536 event buffer size we max out in our driver gives you generally over 2 seconds of activity… do you need that to be longer? Appending buffers to each other in Python is certainly possible, but, expensive.
Hi again,
Thanks for clearifying. It is a concept that takes some getting familiar with
2 seconds should be fine i just want to be able to back trawl the actual time stamp for each event to be able to apply classical signal processing. I figurred it out. It is essentially quite stable around 200Hz sampling (from the binary dump) with these configurations:
# ---------------- Configuration ----------------
EVT_RES = 1024 # Events per read (tune 1024–8192)
CAPTURE_SECONDS = 5 # How long per recording
SAVE_PATH = "/sd/recordings"
MAX_EVENTS = 500_000 # Max events kept in RAM
BRIGHTNESS = 128
CONTRAST = 16
DRAW_PREVIEW = False # Turn off for speed
DUMP_BINARY = True
FPS_REPORT_INT = 5.0 # seconds
# ------------------------------------------------
and it seems to get 5 seconds even 
Processing rec_20131014_203116_000.bin...
Done rec_20131014_203116_000.bin: 280480 events, 199.8 fps over 5.24s
Processing rec_20131014_203122_001.bin...
Done rec_20131014_203122_001.bin: 78112 events, 200.0 fps over 5.03s
Processing rec_20131014_203127_002.bin...
Done rec_20131014_203127_002.bin: 78746 events, 199.8 fps over 5.01s
Processing rec_20131014_203132_003.bin...
Done rec_20131014_203132_003.bin: 76382 events, 199.9 fps over 5.18s
Processing rec_20131014_203137_004.bin...
Done rec_20131014_203137_004.bin: 76885 events, 199.9 fps over 5.03s
Processing rec_20131014_203142_005.bin...
Done rec_20131014_203142_005.bin: 80380 events, 199.9 fps over 5.17s
Processing rec_20131014_203148_006.bin...
Done rec_20131014_203148_006.bin: 82449 events, 199.9 fps over 5.02s
Processing rec_20131014_203153_007.bin...
Done rec_20131014_203153_007.bin: 79079 events, 200.0 fps over 5.03s
Processing rec_20131014_203158_008.bin...
Done rec_20131014_203158_008.bin: 74177 events, 199.9 fps over 5.17s
Processing rec_20131014_203203_009.bin...
Done rec_20131014_203203_009.bin: 74613 events, 200.0 fps over 5.02s
So far I am happy. Thanks a lot!
Awesome!