kiwid restarts after assertion failure in support/coroutines.cpp [fixed in v1.184]

Comments

• jks

  April 2018

  There was a bug fixed in the locking stuff recently. But I've never seen this assertion fail before. If you don't mind I'd like to add some debugging to your Kiwi and see what I can find out.

  
  
• UR5VIB

  April 2018

  Sure, John, go ahead, please.
  
  Ivan,
  UR5VIB
  
  
• jks

  April 2018 edited April 2018

  Okay Ivan, I've got a fix running on your Kiwi and so far it looks good. I was able to write some test code for my Kiwi that caused the assertion failure to occur. So I'm pretty sure that the bug I fixed is really the source of the problem. I'm not sure why it happens so often with your Kiwi. The problem occurs when the GPS acquisition task is started and stopped as the number of user connections changes between zero and greater than zero. That is the only case that uses a special case of the coroutine task sleep/lock code.

  
  

  I'll include this fix in the next update.

  
  

  
• UR5VIB

  April 2018

  Thanks!
  
  I replaced the failed GPS frontend IC (bought on Aliexpress, not sure about it's quality) a few months before, may be it's somehow related to this assertion ocurrence.
  
  Ivan,
  UR5VIB
  
  
• jks

  April 2018 edited April 2018

  No, that shouldn't be related. There was definitely a bug in the task lock code for a special case. It's just that the case only ever occurs when the GPS acquisition is enabled or disabled as users make SDR connections. I was able to trigger the bug on my own Kiwi by artificially increasing the rate of occurrence of the special case.

  
  

  
• UR5VIB

  April 2018

  Hi John,
  
  Found another assertion failure in /var/log/messages:
  
  Apr 24 09:33:20 kiwisdr kiwid: 06:38:06.599 0123      TaskSleepID: pending_sleep =========================================
  Apr 24 09:35:22 kiwisdr kiwid: 06:40:08.656 0123      TaskSleepID: pending_sleep =========================================
  Apr 24 09:38:08 kiwisdr kiwid: 06:42:54.699 0123      TaskSleepID: pending_sleep =========================================
  Apr 24 09:58:13 kiwisdr kiwid: 07:02:59.194 0123      TaskSleepID: pending_sleep =========================================
  Apr 24 09:58:47 kiwisdr kiwid: 07:03:33.403 0123      TaskSleepID: pending_sleep =========================================
  Apr 24 10:00:01 kiwisdr kiwid: 07:04:47.478 0123      TaskSleepID: pending_sleep =========================================
  Apr 24 11:18:34 kiwisdr kiwid: 08:23:20.670 0123      ca_pause -1594 0xfffff9c6 ca_shift=5588 code_creep=45110 code_period_ms=1 code_period_samples=16368
  Apr 24 11:18:34 kiwisdr kiwid: 08:23:20.674 0123      assertion failed: "ca_pause <= 0xffff" gps/channel.cpp line 279
  
  This one is less frequent:
  
  root@kiwisdr:~# grep channel.cpp /var/log/messages
  Apr 23 03:27:38 kiwisdr kiwid: 01:25:36.151 0...      assertion failed: "ca_pause <= 0xffff" gps/channel.cpp line 276
  Apr 24 00:40:49 kiwisdr kiwid: 03:27:48.405 .1..      assertion failed: "ca_pause <= 0xffff" gps/channel.cpp line 276
  Apr 24 11:18:34 kiwisdr kiwid: 08:23:20.674 0123      assertion failed: "ca_pause <= 0xffff" gps/channel.cpp line 279
  
  
• jks

  April 2018

  Thanks for reporting this. As you can see I added some additional debugging in the latest release (the "ca_pause -1594 ..." stuff).

  
  

  I added the assertion a little while ago to make sure a hardware (FPGA) constraint wasn't getting overrun. If it is then a sat that is acquired may not be tracked properly. And we see this behavior sometimes. But this assertion has never occurred in my testing (or at least I've never caught it happening). So if I can understand what's going on and fix a bug this might result in greater tracking successes which would be very helpful.

  
  

  
• UR5VIB

  April 2018

  Thanks John!
  
  Ivan,
  UR5VIB
  
• jks

  April 2018

  I think I understand this issue now. v1.184 has a fix and will no longer panic.

  
  

  Andrew's original code assumed an upper bound in the delay between starting an acquisition and when the "code creep" correction had to be applied at the start of tracking (code creep is a result of sat doppler shift). On his GPS-only system that assumption was completely reasonable. On the Kiwi this bound is much larger because there is much more going on because of the presence of the SDR and a slightly different ca_pause calculation is required.