›

Streaming stops after short while

FrozenKiwiFrozenKiwi
in C#
Hi All,

I'm having an odd issue where my MetaWear C can stop streaming after a while.

If I stop/restart the timer, streaming resumes, again for a limited time.

I recall seeing a thread on here of a similar issue, but now I can't seem to find it.

I'm a bit stuck on idea's on how to debug this.  Does anyone have a suggestion on where to look?

Comments

  • EricEric
    Post your code and firmware / hardware revision strings for the board.
  • FrozenKiwiFrozenKiwi
    firmware : 1.3.4, 
    hardware metawearC 0.3

    The code is fairly simple:

                IAnalogDataProducer adc = gpio.Pins[2].Adc;
                int threshold = Settings.MoistureThreshold;
                // convert from 0-1024 to 1-255 (raw -> byte)
                threshold = (int)(255.0 * threshold / 1024);

                uint streamPeriod = (uint)Settings.TransmitInterval;

                route = await adc.AddRouteAsync(source =>
                    source
                        .LowPass(4).Multicast()
                             // Stream (debugging)
                             .To().Limit(streamPeriod).Stream(data => SendMoisture(data.Value<byte>(), data.Timestamp))
                             .To().Find(Threshold.Binary, threshold).Multicast()
                                .To().Filter(Comparison.Eq, 1).Multicast()
                                    .To().Stream(data => SendTrigger(true, data.Timestamp))
                                    // Blink LED when moisture detected
                                    .To().React(x =>
                                    {
                                        led.EditPattern(MbientLab.MetaWear.Peripheral.Led.Color.Green, Pattern.Solid);
                                        led.Play();
                                    })
                                .To().Filter(Comparison.Eq, -1).Multicast()
                                    .To().Stream(data => SendTrigger(false, data.Timestamp))
                                    .To().React(x =>
                                    {
                                        led.Stop(false);
                                    })
                );

                // Force init read
                adc.Read();
                scheduler = await metawear.ScheduleAsync(250, false, () => adc.Read());
                scheduler.Start();

    After some time the streaming stops.  However, the following action (hooked up to a button) restarts it:

                scheduler.Stop();
                byte v = await metawear.ReadBatteryLevelAsync();
                scheduler.Start();
  • FrozenKiwiFrozenKiwi
    route & scheduler are both class variables (not temporary).
  • FrozenKiwiFrozenKiwi
    After a bit more testing, the streaming stops pretty precisely @ 1 minute after schedule is started
  • FrozenKiwiFrozenKiwi
    Calling 

                var gpio = metawear.GetModule<IGpio>();
                IAnalogDataProducer adc = gpio.Pins[2].Adc;
                adc.Read();

    reads as expected, including setting the LED (ie - the route is intact on the device).  It just seems the scheduler has stopped
  • FrozenKiwiFrozenKiwi
    interestingly - if I change the call to 

    scheduler = await metawear.ScheduleAsync(250, ushort.MaxValue, false, () => adc.Read());
                
    then it continues streaming for a much longer time...
  • EricEric
    Ah, this is a bug with schedule indefinite variant.  It should set repetitions to 0xffff but instead sets it to 0xff which will then stop after 63 seconds.  

    Your modified code is the correct way to create an indefinite scheduler.
  • FrozenKiwiFrozenKiwi
    Thanks for the clarification!  I've been knocking my head against this for the last few weekends!

    Do you mean the variant I have used will continue to notify after the 65K iterations? 

    Right now, I've implemented a watcher to reset the timer if/when I stop receiving messages, which works fine when settings limits of 10-15 seconds.  But it would be nicer if I could forget about this as well!
  • EricEric
    Yes, using 0xffff means indefinite.
This discussion has been closed.