ArduCam and libcamera

@byron I agree, it's what I use, my memory tells me it was a no-brainer to set up.

I will withhold my welcome back until sufficient time passes to show me it is warranted. I may have some mqtt questions although I figured out what I wanted pretty quickly so who knows.

Posted by: @zander

↑

I will withhold my welcome back until sufficient time passes to show me it is warranted.

Ron,  withholding is not good for an old fellow, let it all flow... 😀   Looking back over the posts for the last few weeks I see you are mightily prolific and helpful to all those asking for help.  Very commendable.  Now you just need to learn some python. (oh and learn to use classes in c++ ). 😎

@byron Too old to learn new languages and really no need now as AI will probably do it for me.

@byron 

I have used both VNC and ssh to run my Raspi code headless, but this particular situation persists with either approach

@emeyeraway  - just to be clear - are you saying that you can run your code OK on your rpi connected to a monitor via its htmi port, but the exact same code (exact - no extras like --qt-preview ) will not produce the same results when your 'monitor' is a vnc client running on a PC or mac ?

Hi @emeyeraway,

  Looking at your reply to me, plus some of the input from Ron @zander, I think you need to go to back to some basics. Obviously, I can't see your set up, so the following includes assumptions.  Apologies, if any assumptions are false.

  I don't think your 60 second behaviour is fundamentaly related to the software program ... although it is being driven a bit crazy, trying to keep up with spurious requests from the PIR sensor board.

I am assuming that you have something like the board that Ron identified, and I also found by a little Googling.

 which I found at https://cdn-learn.adafruit.com/downloads/pdf/pir-passive-infrared-proximity-motion-sensor.pdf

I don't know how it happened, but I suspect your initial 'success' was due to the settings (jumper positions, potentiometer positions, etc.) being in one state, but in a different state subsequently. I think the first thing is to ignore the software and camera for a while, and concentrate on getting the PIR to give you a pulse when, and only when, it is supposed to. When you have done that, then return to the software etc.

So starting with just that PIR sensor board and a power supply.

Than monitor the output ... you could probably use a meter or connect up an LED as suggested in the Adafruit reference

I guess you are powering the PIR with a 5V (or less) supply, not 4 cells as suggested in the above diagram. The 5V supply should be fine for the LED .. it will just be little dimmer.

The Adafruit reference gives some guidance on how to change the settings on the board.

You need to get to stage where the output only goes high when you trigger it with a moving hand/body ... not because a timer has expired, etc.

Remember that even the shortest high going pulse will trigger your software program so beware of creating a system that produces false pulses that are too short to light the LED or register on your meter.

---------

Only when the LED is behaving sensibly, consider reconnecting your PICO and looking at software.

---

Once you think it is working with an LED or meter, them connect the Pico, but start with a minimal program that just samples the input pin and reports a change of state. Use this to double check the PIR is behaving correctly, before including the camera functions.

----------------------

Hope it works and you are successful. I am concerned that Ron mentions

everything I read about the PIR sensor tells me this thing cycles and even has 2 adjusting pots as seen in the picture I posted. It is this cycling behaviour that ruled it out as an intrusion detection sensor for my use

I can't rule out the possibility he is right, but I am hoping (for your sake), you can change the jumpers and potentiometer settings to find a 'sweet spot' that works as you expect - I am not surprised it needs a little care to set up correctly, but it seems illogical that it is impossible to use!

Best wishes, Dave

@davee @emeyeraway

It could very well be related to the electronics, but my current main suspect is how the rpi is being run 'headless'  as I see the library uses qt to do something with a preview display and qt runs in its own event loop.  (constantly trying to refresh it preview display perhaps)

However running the rpi via a vnc client should simply reproduce the exact same output as can be seen on a directly connected monitor.  In fact you can connect both a directly connected monitor and a vnc client screen running on another computer and see the exact same output on both.   Indeed that may the next step if the electronics angle does not prove fruitful.   Connect the rpi to both a monitor as well as a vnc client and see if the vnc connection is upsetting the camera library for some reason.   When using VNC, as far as the programs running on the rpi are concerned they don't know anything about whether they are being view via an htmi connection or a VNC connection.  But strange things sometimes happen. 😉   

If we are saying that the program has problems when running on a rpi when connected to a monitor directly then that a whole different problem of course.

@byron @emeyeraway I think Byron might be onto something. My thinking is that since the only visible difference between the two sketches is the addition of --qt-preview then it is worth looking at what that switch does. Why not try running the same setup again in headless mode BUT leave out the preview option. Maybe clip a VOM to pin 17 to see if any activity is detected.

Hi @byron + @emeyeraway,

A couple of thread pages back, @emeyeraway replied to my penultimate posting on this thread, saying :

I disconnected the sensor output lead from pin 17 and connected it to a voltmeter, and it is definitely outputting 3.3V every 60 seconds. I don’t know what is telling the sensor to go high, but it is the source of the high to pin 17.

Which unless I am missing something obvious or confused by that sentence means, suggests that all the discussion about running RPi s, with or without their head, is a red herring as regards the main problem ...

I am not sure what game the PIR sensor is playing .. I assume it is related to trying not to produce multiple triggers from the same object, and/or power saving ... but it seems like it's detection circuit can produce a gently oscillating output at about 60 seconds/cycle rate.

Hence my suggestion of giving the RPi/Pico a short vacation, and concentrate on getting the PIR do do its job properly first.

Best wishes, Dave

@davee @emeyeraway @byron In the 7th post I said I was confused re the voltmeter reading, is it pin 17 or the PIR output pin that is going HIGH every 60 secs. I suspect it is the output pin of the PIR and I also suspect that is normal for that PIR with the jumpers and settings on the PIR board. It appears the OP did not take my advice so we are left to continue guessing. Now I would add a further test, do that measurement (actually 2, one on pin 17, one on PIR, in both cases with PIR disconnected from pin 17) once when headless and a second time when not headless. I bet the PIR doesn't change.

Hi Ron @zander + @emeyeraway @byron,

 Ron, our posts may have crossed in the ether However, to clarify, in my last post I quoted  @emeyeraway who a couple of pages back answered my post saying:

I disconnected the sensor output lead from pin 17 and connected it to a voltmeter, and it is definitely outputting 3.3V every 60 seconds. I don’t know what is telling the sensor to go high, but it is the source of the high to pin 17.

Surely this is the same as:

Now I would add a further test, do that measurement (actually 2, one on pin 17, one on PIR, in both cases with PIR disconnected from pin 17) once when headless and a second time when not headless. I bet the PIR doesn't change.

So Ron, you have a very good chance of winning that bet, assuming you mean that the PIR output is pulsing (when disconnected from the Pico/R Pi) but the RPi/Pico input pin is not, regardless of whether it is headed or headless! 😀 

Best wishes all, Dave

@davee @zander @emeyeraway

I like a nice who whodunit 😀   For sure test the PIR on its own is probably the first thing to check as it should not take long and to see if its pulsating its output every 60 seconds when just connected to power and ground (and any pullups or pulldowns that are specifed)  Then we've may have the culprit.  

But, if it still works when connected to the rpi3 (not a pico) then we are on to the next suspect.   I suspect the camera software instructions concerning remote use is alluding to the case where no monitor is available.  And by no monitor I also include no remote monitors such as  VNC.  

Using ssh is universal to most computers I think, thus 'headless' in their terms is giving instructions as to how to universally connect with ssh.   Headless in rpi terms usually just means viewing the computer screen remotely.  It picks up the output to the screen, which can be the output to the htmi screen (or it can be a different screen - hmm I've probably not explain that point too well but it irelevant to this whodunit.).  So if it works on the rpi3 then it should work over VNC without further ado.  If the camera software speak of adding the --qt stuff for headless operation was taken to mean it would be necessary when using VNC then I think this is mistaken.

Nevertheless, Ron may still get the cherry.

@davee @emeyeraway @byron My bad, I failed to notice the next sentence that clearly disambiguates the first sentence. It IS in fact the sensor cycling and I will bet dollars to doughnuts that is happening in the first sketch as well. If we could just get the OP to follow instructions (a common problem) we could help, but now we are guessing.

To be clear, place a VOM on pin 17 with the sensor attached, it doesn't matter if it is or isn't, then run sketch one, followed by sketch 2. Does the VOM show 60 second cycling in only the second case, or in both?

If it is in both, then that is 'normal' operation and he needs to consult the documentation to change the settings to work the way he wants, however, if it is only the second sketch then the preview option is the cause of the problem, the fix is to remove the preview option.

@byron @davee @emeyeraway If we assume the PIR is always pulsing, how come the OP didn't notice all the files being created in sketch 1?

Hi Ron @zander + @byron @emeyeraway ,

 Re: If we assume the PIR is always pulsing, how come the OP didn't notice all the files being created in sketch 1?

  I don't pretend to follow all the twists of this tale, but if by sketch 1, you mean @emeyeraway's early experience, then (as I suggested previously), I think it is possible the PIR board's settings were different .. there are two potentiometers, plus jumpers, the scope of which is somewhat unclear to me ( I have only the Adafruit reference to read, whose explanation is not as clear as I would like,  and no hardware to examine), but at least one of the potentiometers affects the timing characteristics.

Anyway, assuming PIR board, when only connected to power (ie no connections to PICO/R Pi), is producing an output pulse every 60 seconds, regardles of sensing any objects, then surely that is the root of the reported problem.

Whether the problem is solvable by adjusting the potentiometers and jumpers, I have no idea, but it seems worth a try. Why a PIR board that produces a pulse every x seconds, regardless of whether it has detected an object, would be produced and sold I cannot imagine, so I am presuming it only does this when maladjusted.

Of course, this may be just wishful thinking on my part and the board could be a 'fake' or faulty.

Best wishes, Dave