I'm creating a sort of sound alarm system, where a Webcam's microphone 
is input to a csd running on a RPi. The rms level is constantly sent to 
another Rpi over OSC. In this second Pi csound sends the data over 
serial to an Arduino board. If the signal is above a certain level, a 
LED lights up.

So:

webcam microphone-> RPi 1-->OSC-->Rpi 2-->serial-->Arduino

This works fine for a few minutes, but then nothing happens at the 
second Pi, no new values come in, while Pi 1 is happily sending data all 
the time. I have to use Wifi here, that might be a problem?
I guess Csound's OSC uses UDP so there is no way of knowing the data 
arrived Ok, or maybe my sending csd is wrong.
I was thinking of reconnecting OSC to the Pi2 after a period of 
inactivity. (What was that opcode again that measures the running time 
of an instrument?)

Any other suggestions?

Richard

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

OSC is always through UDP, whichever system you use, so it can drop packages
alright, but I would expect it to be OK over wifi. I have used OSC over wifi in a
concert (with Tarmo’s group) and had no problems. Tarmo uses it all the time as
far as I can see, so he might be one to give advice on this.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 11 Dec 2016, at 18:14, Richard  wrote:
> 
> I'm creating a sort of sound alarm system, where a Webcam's microphone is input to a csd running on a RPi. The rms level is constantly sent to another Rpi over OSC. In this second Pi csound sends the data over serial to an Arduino board. If the signal is above a certain level, a LED lights up.
> 
> So:
> 
> webcam microphone-> RPi 1-->OSC-->Rpi 2-->serial-->Arduino
> 
> This works fine for a few minutes, but then nothing happens at the second Pi, no new values come in, while Pi 1 is happily sending data all the time. I have to use Wifi here, that might be a problem?
> I guess Csound's OSC uses UDP so there is no way of knowing the data arrived Ok, or maybe my sending csd is wrong.
> I was thinking of reconnecting OSC to the Pi2 after a period of inactivity. (What was that opcode again that measures the running time of an instrument?)
> 
> Any other suggestions?
> 
> Richard
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>       https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have had problems with wifi connection on an Andoird tablet running
the Lemur app. I think it communicates via OSC to the daemon running
on my laptop. It might drop the connection after a while, I suspect it
has to do with some power saving scheme somewhere, even though I have
turned off everything that relates to power saving everywhere there is
a setting for it. Just to chime in that I recognize the intermittent
dropping of the connection. Not reproducible by waiting any specific
amount of time (which perhaps contradicts my blame on some power
saving scheme, as one would expect it to be related to a timer
somewhere).

But, an idea for a watchdog script would be:
- send a periodic signal from RPi1 to RPi2 (metro trigger some "I am
alive" kind of message over OSC or other network connection), you can
use any period you see fit, I would use a period around 5 or 10
seconds unless it is critical that the connection *always* works
without interruption (in case you would not use wifi, I guess)
- also send a similar periodic signal from RPi2 to RPi1, this way we
have a two-way watchdog connection.
- on the receiving end, start a timer each time the message is
received, if twice (or a little bit more) the expected time between
messages has passed without receiving a sign of life, try to
reconnect.
- if you can not reconnect from the receiver side, send message to
sender (via the connection going the other way), asking it to
reinitialize the connection. If it still fails, try to reinitialize
the connection with a new port number.
- if both sides of the connection seems dead (the previous attempts
unsuccessful for something like 2 minutes or so), reinitialize the
whole setup.
* If you really want to make sure the system can take care of itself
unsupervised, add another watchdog scipt on each RPi, to check if the
first watchdog is running (just checking that the main program is
still running on the local computer, no network).
* And, you might set up the watchdog processes to send you an email in
case of any irregularity. Adjust threshold of mishap before sending
email to your preference. If you let it send email every time there is
a small glitch, you might get more emails that you appreciate.
* If you have an audio process running, you can also check for silence
(average rms over some period), and send warning/watchdog/reset/email
if needed
* Similarly, you could probably check if the camera is still working
by comparing images. If nothing have moved in the room, the image
would be very similar, but some noise is probably there if it produces
new images of the same scene. If the camera has frozen the image will
be exactly the same, no noise or other minor variation.

The camera checking procedure is something I haven't tried, but the
rest of it I've used in long running sound installations so I don't
have to continuously check if they are still running. For example the
Flyndre installation is currently in its 11th year...
I've been meaning to clean up some examples to show how to do this,
but still haven't gotten around to doing it. Bernt Isak helped me
produce some of the initial code, so he might also have additional
insights into details I've forgotten to mention here.

all best
Oeyvind

2016-12-11 10:49 GMT-08:00 Victor Lazzarini :
> OSC is always through UDP, whichever system you use, so it can drop packages
> alright, but I would expect it to be OK over wifi. I have used OSC over wifi in a
> concert (with Tarmo’s group) and had no problems. Tarmo uses it all the time as
> far as I can see, so he might be one to give advice on this.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 11 Dec 2016, at 18:14, Richard  wrote:
>>
>> I'm creating a sort of sound alarm system, where a Webcam's microphone is input to a csd running on a RPi. The rms level is constantly sent to another Rpi over OSC. In this second Pi csound sends the data over serial to an Arduino board. If the signal is above a certain level, a LED lights up.
>>
>> So:
>>
>> webcam microphone-> RPi 1-->OSC-->Rpi 2-->serial-->Arduino
>>
>> This works fine for a few minutes, but then nothing happens at the second Pi, no new values come in, while Pi 1 is happily sending data all the time. I have to use Wifi here, that might be a problem?
>> I guess Csound's OSC uses UDP so there is no way of knowing the data arrived Ok, or maybe my sending csd is wrong.
>> I was thinking of reconnecting OSC to the Pi2 after a period of inactivity. (What was that opcode again that measures the running time of an instrument?)
>>
>> Any other suggestions?
>>
>> Richard
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://www.partikkelaudio.com/
http://crossadaptive.hf.ntnu.no
http://gdsp.hf.ntnu.no/
http://soundcloud.com/brandtsegg
http://flyndresang.no/
http://soundcloud.com/t-emp

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks Oeyvind,

I've been thinking along the same way about using watchdogs. I will 
first try Tarmo's idea about using websockets, might be less work.
I am not using the camera images in this setup. Since it is at our door, 
I do use the 'motion' program to check for changes. If any, pictures 
will be taken and stored in a folder. Very convenient.

Thanks for your idea's. Talking about guards: for my work I once created 
an 'Ueberguard' - as I called it- a program for checking if other guards 
or processes are still running.

Richard


On 12/12/16 04:34, Oeyvind Brandtsegg wrote:
> I have had problems with wifi connection on an Andoird tablet running
> the Lemur app. I think it communicates via OSC to the daemon running
> on my laptop. It might drop the connection after a while, I suspect it
> has to do with some power saving scheme somewhere, even though I have
> turned off everything that relates to power saving everywhere there is
> a setting for it. Just to chime in that I recognize the intermittent
> dropping of the connection. Not reproducible by waiting any specific
> amount of time (which perhaps contradicts my blame on some power
> saving scheme, as one would expect it to be related to a timer
> somewhere).
>
> But, an idea for a watchdog script would be:
> - send a periodic signal from RPi1 to RPi2 (metro trigger some "I am
> alive" kind of message over OSC or other network connection), you can
> use any period you see fit, I would use a period around 5 or 10
> seconds unless it is critical that the connection *always* works
> without interruption (in case you would not use wifi, I guess)
> - also send a similar periodic signal from RPi2 to RPi1, this way we
> have a two-way watchdog connection.
> - on the receiving end, start a timer each time the message is
> received, if twice (or a little bit more) the expected time between
> messages has passed without receiving a sign of life, try to
> reconnect.
> - if you can not reconnect from the receiver side, send message to
> sender (via the connection going the other way), asking it to
> reinitialize the connection. If it still fails, try to reinitialize
> the connection with a new port number.
> - if both sides of the connection seems dead (the previous attempts
> unsuccessful for something like 2 minutes or so), reinitialize the
> whole setup.
> * If you really want to make sure the system can take care of itself
> unsupervised, add another watchdog scipt on each RPi, to check if the
> first watchdog is running (just checking that the main program is
> still running on the local computer, no network).
> * And, you might set up the watchdog processes to send you an email in
> case of any irregularity. Adjust threshold of mishap before sending
> email to your preference. If you let it send email every time there is
> a small glitch, you might get more emails that you appreciate.
> * If you have an audio process running, you can also check for silence
> (average rms over some period), and send warning/watchdog/reset/email
> if needed
> * Similarly, you could probably check if the camera is still working
> by comparing images. If nothing have moved in the room, the image
> would be very similar, but some noise is probably there if it produces
> new images of the same scene. If the camera has frozen the image will
> be exactly the same, no noise or other minor variation.
>
> The camera checking procedure is something I haven't tried, but the
> rest of it I've used in long running sound installations so I don't
> have to continuously check if they are still running. For example the
> Flyndre installation is currently in its 11th year...
> I've been meaning to clean up some examples to show how to do this,
> but still haven't gotten around to doing it. Bernt Isak helped me
> produce some of the initial code, so he might also have additional
> insights into details I've forgotten to mention here.
>
> all best
> Oeyvind
>
> 2016-12-11 10:49 GMT-08:00 Victor Lazzarini :
>> OSC is always through UDP, whichever system you use, so it can drop packages
>> alright, but I would expect it to be OK over wifi. I have used OSC over wifi in a
>> concert (with Tarmo’s group) and had no problems. Tarmo uses it all the time as
>> far as I can see, so he might be one to give advice on this.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>>> On 11 Dec 2016, at 18:14, Richard  wrote:
>>>
>>> I'm creating a sort of sound alarm system, where a Webcam's microphone is input to a csd running on a RPi. The rms level is constantly sent to another Rpi over OSC. In this second Pi csound sends the data over serial to an Arduino board. If the signal is above a certain level, a LED lights up.
>>>
>>> So:
>>>
>>> webcam microphone-> RPi 1-->OSC-->Rpi 2-->serial-->Arduino
>>>
>>> This works fine for a few minutes, but then nothing happens at the second Pi, no new values come in, while Pi 1 is happily sending data all the time. I have to use Wifi here, that might be a problem?
>>> I guess Csound's OSC uses UDP so there is no way of knowing the data arrived Ok, or maybe my sending csd is wrong.
>>> I was thinking of reconnecting OSC to the Pi2 after a period of inactivity. (What was that opcode again that measures the running time of an instrument?)
>>>
>>> Any other suggestions?
>>>
>>> Richard
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>          https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here