Version n+1 wish list. #98
Comments
|
Hi Pete, The good news is that some of this is already available and others are underway:
This is being developed at the moment. It will require either a new PCB, or a small (postage-stamp sized) daughterboard to add the extra components to read the voltage. The "Gen 2" PCB is a CY2022 project I'm already prototyping, and the daughterboard I'm hoping to have available before Christmas 2021. Initially it will only report the hourly voltage over a rolling 24-hour period, but a subsequent release will add alarming whereby if the voltage falls outside of user-set limits the Arduino will wake the Pi to send an off-box alarm.
The intvlm8r currently reports both the temperature of the Pi's die, and also the value reported by the real time clock's in-built temperature sensor, the latter of which should be a very close approximation of the real internal temperature. Are you finding that value not sufficiently accurate? At about the same time as battery alarming is added I'll also be doing same for thermal limits.
What sort of status info are you wanting to see, and how would that be presented to the user? (This is in addition to the progress messages below?)
That one's going to be a challenge to resolve for you as I'm not able to reproduce problems, and there's always the question as to which end of the line is causing this - or if it's the bearer in the middle. Let me stick a post-it on my monitor...
To some degree that's coming as part of "Gen 2", and will be offered with the SMT components populated (as a "bare-bones" board) as well as fully built and tested. The board won't be any smaller, as I'm adding extra functionality with the voltmeter components as well as a switched USB power supply for an off-board 4G dongle (which lives under the Pi).
I use a Pi 3B+ on my bench when I'm developing (purely for speed of reboots), and it works well. (Santa might upgrade me to a 4). Because the Pi's all use the same GPIO header this is a really easy update - but as you say, is most likely limited to those who have mains power. Here's some more info on how to do that: Other Pi Models
When background tasks like copies and transfers are running, your browser polls the Pi every 2s for an update, and as a result the updates jump rather than be increment singularly. (e.g. "now copying 2 of 80... 6 of 80... 10 of 80"). I'm trying to provide feedback to the user but at the same time not burden the poor little Pi Zero with overhead that's distracting from the tasks at hand. Is there value to the on-screen copy info including a filename and not just "image x of y"? What else does it need?
I added "rename on copy" in v4.3.0, allowing you to add time and date values to the filename when it's copied across from the camera. This uses the time and date stamps from the *file* and not the EXIF data.
Yeah, ta. While we're locked down the intvlm8r is now my M-F "job" - as you might see from all the release updates this year. I'm hoping to be allowed out to play soon, and maybe one day even travel! - G. |
|
Hi Greig, not sure if I mentioned it before but it would be good if the transfer from camera to pi took place before the transfer to dropbox etc. The extra time taken would be of little consequence but having all of the current images a day earlier would be great. Just for info, my camera has been running outside now for around 3 months on solar/4g without missing a single frame. Battery voltage hasn't been an issue so far, even with the british weather. |
|
Hi; aerialvideographyuk;
The version of intvlm8r I am running already has this behaviour. I have the
pi set to wake up at 7:00pm each evening, the first thing it does is to
copy images from the camera to the pi and then it transfers those images
via ftp to my local storage.
The camera to pi process always completes with no issues, however the
piTransfer process almost always fails probably due to poor WiFi and a slow
NAS. I have mains power available so battery life is not an issue for me.
I have ordered a Raspberry Pi Ver 4 which I understand supports the 5G WiFi
band so I am expecting this will fix some or all of my piTransfer issues.
My intvlm8r has been running for about 6 months now but we have only seen
site works for our new build in the last 4 weeks so there is a lot of clean
up to do on the NAS to dump all the boring bits.
Cheers Pete.
…On Tue, 5 Oct 2021 at 19:30, aerialvideographyuk ***@***.***> wrote:
Hi Greig, not sure if I mentioned it before but it would be good if the
transfer from camera to pi took place before the transfer to dropbox etc.
The extra time taken would be of little consequence but having all of the
current images a day earlier would be great. Just for info, my camera has
been running outside now for around 3 months on solar/4g without missing a
single frame. Battery voltage hasn't been an issue so far, even with the
british weather.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#98 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4FTDL2GTVIMUI6VSGC6ILUFK5BXANCNFSM5FJBHUKA>
.
--
Peter
|
|
OK - I still haven't got round to updating to the latest version so I will have to do that. Like you I get the pi to wake up at 7pm but I only get the previous days images plus a few of the images from the current day. The rest of the images I get the next day. I haven't got the luxury of mains and wifi so solar and 4g is what I use. I transfer to a dropbox free account and then use a windows script to move to my local NAS. That seems more reliable than ftp to my NAS. |
|
Pete, I've just added a retry to FTP and SFTP transfers, so if it fails to upload an image it will wait 1s and try one more time before abandoning it and moving on. Hopefully that brings you a measurable improvement. It will be in release 4.3.3, due out at the start of November. - G. |
|
Greig;
Thanks for that change, I’ll look forward to reporting back to see if it
fixes my issue.
Cheers Pete.
On Thu, 7 Oct 2021 at 14:05, Greig Sheridan ***@***.***> wrote:
Pete, I've just added a retry to FTP and SFTP transfers, so if it fails to
upload an image it will wait 1s and try one more time before abandoning it
and moving on. Hopefully that brings you a measurable improvement. It will
be in release 4.3.3, due out at the start of November.
- G.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#98 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4FTDKORU5RGL43VAS2HOLUFUIPBANCNFSM5FJBHUKA>
.
--
Peter
|
|
I had to release 4.3.3 this morning to address a bug, so this change will be in 4.3.4, still scheduled for the start of Nov. |
|
Hi, Do I understand this "issue" as a general wish list of future functions, which can be discussed and I would also like to help to implement? One thing which comes to my mind and could potentially be beneficial is a second communication channel to the outside world. I think in general of a LoRa connection. I see three benefits, first, a mobile connection can be turned off when just telemetry is transferred, and secondly, when the power is too low for all the main components, a backup communication can be established. As a third point, the LoRa connection could be used as a backup, in case the main channel is broken. So I still get notified that my camera takes pictures, but just at the moment they cannot be transferred (broken 4G-Stick, broken Network connection, etc.) What do you think? |
|
Hi @SchmidL , yes this is a general wish-list "issue", and I welcome suggestions and offers to help. My main goal in any project enhancements is to work within the current hardware constraints, so the new features are available to all existing users. Having said that, a "Gen 2" version of the board is slowly taking shape in the background, as referenced earlier. LoRa interests me, but to add LoRa will require more hardware, and presumably also another micro-controller. Do you know of any LoRa-enabled boards that are pin-compatible with the Arduino Pro Mini, so it could be a drop-in replacement? (It will need to have IO pins that run at 3.3V because of the I2C interface to the Pi). If it's another board, have you thought about how it might be interfaced with the existing circuit? The Arduino and Pi will run down to an input voltage of ~6V (which is a VERY flat 12V battery!), and when I can get the battery monitoring alarm built and coded the intvlm8r will have called for help long before it reaches that point - so having LoRa as a backup comms channel mightn't be all that beneficial if there's not enough power to take photos, suck images from the camera, or run the Pi. Also, if we're using the intvlm8r as a LoRa sender, it will presumably need a companion device that is the receiver with presumably its own uplink to the Internet. Do those exist commercially, or will that still need to be created and coded? Perhgaps we should spin LoRa into a free-standing issue if you'd like to banter it around some more? - G. |
This request has been added in Release 5.0.0, with "Transfer after Copy":
|
Hi Greig and Rocky.
If you are looking for suggestions or enhancements see below for my thoughts.
enhancement wish list.txt
Enjoy your "retirement"
Cheers Pete.
The text was updated successfully, but these errors were encountered: