New version 1.48.2 to test before final release

Here you'll find the updated available
Post Reply
Jan Volk
Posts: 71
Joined: Wed Mar 03, 2021 1:35 pm
Been thanked: 23 times

Re: New version 1.48.2 to test before final release

Post by Jan Volk »

Francesco,

I managed to install a Linux distribution on my Raspberry Pi 3 and unpack the new Annex Toolkit 1.1 with Annex32 1.48.22 and move the .bin files to my Windows build folder and load them with Annex TK 1.22.
The ESP32 CAN 1.48.22 with new font is the same for Wlog and for all folders and the operation: OK
The ESP32 BLE CAN 1.48.22 with new font is the same for Wlog and for all folders and the operation: OK
Now Print and Wlog gives the same result. Thank you.

Jan Volk
Jan Volk
Posts: 71
Joined: Wed Mar 03, 2021 1:35 pm
Been thanked: 23 times

Re: New version 1.48.2 to test before final release

Post by Jan Volk »

Francesco,

I said all folders , but only the font in Wlog and the folders accessed from the Editor to Open are the same font.

Jan Volk
rmsta
Posts: 32
Joined: Sat Feb 20, 2021 9:36 am
Location: Sindelfingen, Germany
Has thanked: 132 times
Been thanked: 9 times

Re: New version 1.48.2 to test before final release

Post by rmsta »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Tue Nov 29, 2022 6:16 pm I can contribute two more "silent users" behind me :-)
:D

Hi,
I am dealing with a strange behavoiur when executig a camera.picture("filename") which saves a picture to file.
The picture seems not to be saved when the command is executed but a picture somehow significant earlier is taken ?
I could verify with a very simple program, that takes pictures in 5 second timesteps from my smartphone
showing a digital clock (which is very much in line with time$):

Code: [Local Link Removed for Guests]

dim f$(3)
for i=1 to 3
f$(i)="/pic"+str$(i)+".jpg"
wlog i,f$(i)
wlog file.delete(f$(i))
next i

t$=time$
wlog camera.picture(f$(1))
pause 5000
wlog camera.picture(f$(2))
pause 5000
wlog camera.picture(f$(3))


wlog t$, time$
end

With the the command http://module_ip/picture and pressing F5 all is in good order.
Maybe my ESP32 CAM module has some defect, I ordered alread another one.
Is there a similar experience with the camera.picture command ?
Rainer
User avatar
PeterN
Posts: 366
Joined: Mon Feb 08, 2021 7:56 pm
Location: Krefeld, Germany
Has thanked: 171 times
Been thanked: 203 times
Contact:

Re: New version 1.48.2 to test before final release

Post by PeterN »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Thu Dec 01, 2022 7:06 pm
[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Tue Nov 29, 2022 6:16 pm I can contribute two more "silent users" behind me :-)
:D

Hi,
I am dealing with a strange behavoiur when executig a camera.picture("filename") which saves a picture to file.
The picture seems not to be saved when the command is executed but a picture somehow significant earlier is taken ?
I could verify with a very simple program, that takes pictures in 5 second timesteps from my smartphone
showing a digital clock (which is very much in line with time$):
...
With the the command http://module_ip/picture and pressing F5 all is in good order.
Maybe my ESP32 CAM module has some defect, I ordered alread another one.
Is there a similar experience with the camera.picture command ?
Rainer
I can confirm this with M5Camera and AnnexCam 1.48.22
With AnnexCam 1.43.x all was OK
Maybe this corresponds to my post about the non reaction to a change of the framesize - as the actual framesize maybe the size of an earlier picture.
User avatar
cicciocb
Site Admin
Posts: 1889
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 405 times
Been thanked: 1261 times
Contact:

Re: New version 1.48.2 to test before final release

Post by cicciocb »

This is probably because there is a circular buffer with 4 frames, probably the one that is saved is 3 frames late.
User avatar
PeterN
Posts: 366
Joined: Mon Feb 08, 2021 7:56 pm
Location: Krefeld, Germany
Has thanked: 171 times
Been thanked: 203 times
Contact:

Re: New version 1.48.2 to test before final release

Post by PeterN »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Thu Dec 01, 2022 8:27 pm This is probably because there is a circular buffer with 4 frames, probably the one that is saved is 3 frames late.
YES - that makes sense and explains the confusion:-)
rmsta
Posts: 32
Joined: Sat Feb 20, 2021 9:36 am
Location: Sindelfingen, Germany
Has thanked: 132 times
Been thanked: 9 times

Re: New version 1.48.2 to test before final release

Post by rmsta »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Thu Dec 01, 2022 8:27 pm This is probably because there is a circular buffer with 4 frames, probably the one that is saved is 3 frames late.
This would explain a lot. Btw. I did some testing with my "program", if I simply take 2 pictures every time, always one dummy picture before the desired one, all is working fine. In the dummy picture the "last" picture is found.
Post Reply