L2C capability monitor #606
Conversation
|
@adel-mamin @ljbade @jacobmcnamee Please, review. |
| void l2c_capability_get(u32 *l2c_cpbl) | ||
| { | ||
| chMtxLock(&l2c_capability_upd_mutex); | ||
| *l2c_cpbl = gps_l2c_sv_capability; |
|
Test FAILed. |
|
|
||
| int fd = cfs_open(L2C_FILE, CFS_WRITE); | ||
| if (fd != -1) { | ||
| if(cfs_write(fd, |
There was a problem hiding this comment.
Flash writes from the decoder thread scare me a little bit. I don't know what the maximum write time is, but if we do this for several channels back to back it might cause the nav bit FIFOs to overrun. Right now the FIFOs are 32 nav bits per channel, which can be as little as 64ms for some encodings.
I think doing the writes directly can be ok as long as we're sure timing won't be violated, but a better option might be to set a flag and periodically write to flash from a background thread when necessary (assuming the write can be done in a way that doesn't block the decode thread).
There was a problem hiding this comment.
@jacobmcnamee Since all SVs send SV config data for whole constellation incoming L2C data is same from all channels. Current algorithm monitors changing L2C capability data, so if we update it from one channel it will not updated from others. Worst case is flash writing rate is once per 12.5 mins.
The functionality allows to obtain SV config data from L1CA nav message
|
#630 should be merged first. |
4 participants
https://github.com/swift-nav/exafore_planning/issues/38