I can take a picture directly into a 60w light bulb and the image file stays below 40k bytes, mainly because the image compensates and only the bulb is bright yellow and the surrounding area is darker, unlike the outside images which are more bright white in color.
I can’t get the light bulb to look as bright as the outside daylight pictures so it’s not a fair comparison.
The brighter the image overall the easier it is to go over 40k.
I guess we need @Vitesze to test with a Photon and see if he is seeing this same issue or not also. If he does not see this same issue then maybe I have a bad unit or it may be running different firmware.
Maybe my cam is just enough out of focus to have the cam opt for a higher compression factor.
Getting the focus adjusted might be "fun"
Update:
So after some fiddling and finding some high detail objects to snap, I managed to get my image size up to 54KB and so I gave in and reworked the sample to avoid the static buffer for JPGs.
Try this - not as neat I'd like it, but it at least doesn't crash: https:/go.particle.io/shared_apps/5aca127ccb4e0394fe000508
Latest revision: Particle Web IDE
Yup, raw images will never get bigger then that and are not sent by the cam in slices which could cause some data loss when the remote transfer takes too long. So for raw images I still use the static buffer to consume the whole image in one go before transfer.
For JPG the cam provides a way to request one slice of up to 506 (+6) byte at a time when you’ve got time to consume it.
I haven’t yet pushed the new release as I wanted to hear back from you first and maybe also finish off the TCPClient part for Electron support.
I left your application running with the web browser updating the image every 7 seconds automatically and I’m getting a reliable image update over the course of the day without any lockup or code freezing issues.
I’m impressed with the cameras low light performance, it will provide a pretty clean image even in almost dark conditions. Better than I expected it to perform in low light.
I ordered the 116-degree wide angle lens from Digikey since the image is very narrow with the stock lens.
@Vitesze I’m pretty sure you’re going to want the wide angle lens for your application.
@ScruffR Your code is a good example of how the Photon can serve up its own web pages.
This camera setup is a powerful and useful acessory in my opinion.
This will be very handy to get images back from Electrons out in the wild. Lot’s of ways that combo could be put to use.
@ScruffR@RWB I’m still waiting for my Photon to arrive. Once I have it here, I will test out the new firmware ASAP and let you know whether it works fine for me as well
Thanks for the pictures, as you stated @RWB , a wide-angle lens indeed is necessary for my project
Update: @Vitesze & @RWB, I’ve now “completed” the example to also support a TCP data sink.
I haven’t yet tested with an Electron, but a simple NodeJS server running on any computer can receive the images and stores them as #####.jpg in an out folder.
Since JPEG will probably be used the most, for laziness I even save the BMP images that way However the sample server can be modified to look for the BMP header and choose the correct extension.
Before I publish the library I’d like your input about it - it might be not as solid as it was before, due to size of the static buffer to allow for all possible formats while avoiding dynamic memory allocation and longer latency with remote servers (especially on Electron).
I tried the example code as well, but on the Photon webserver when I click ‘‘Click’’, the Photon doesn’t send any image data. Instead, it drops the connection and then instantly reconnect…
Not really sure what I’m missing here? I’m using the default code including the uCAMIII and WebServer libraries. Camera is still connected to TX/RX. I actually never used a Photon before, so not sure if I’m missing something crucial and Photon-specific here.
Note: using the 4D App, I can take imagery just fine.
EDIT: Odd…the issue seems to have been resolved for now. Not sure where it came from, as I didn’t change anything. It’s actually pointed at a lamp, so possibly the illumination caused the image file to be too large for the Photon?
Be sure to run a wire from RESET on the camera to pin A0 on the Photon.
The bright lightbulb should not cause any issues with Scruffs latest firmware.
If you have this setup on a breadboard then loose jumper wires can cause issues. I have wires running directly from the camera pins to the Photon pins for a better connection.
You can load a Firefox web browser app called auto reload and it will allow you to automatically reload the camera image every 7 seconds automatically if you want it to act like a constantly refreshing webcam for testing.
I wasn’t able to reproduce the issue again…I had only just claimed my Photon device, so perhaps that was the culprit somehow. Other than that, the camera is looking really good!
@ScruffR We could go with one standard format if it makes things easier? e.g. 320x240; I most likely will not need anything else, or 640x480 which is probably going to be popular among other users
Here is my “first” JPG taken with uCamIII on an Electron.
Due to the slower transfer via cellular the pic takes considerably longer to transfer to the NodeJS TCP server and hence the Particle.function() call returns a failuer, nevertheless the image gets delivered correctly.
Just be aware, to run the uCamIII on an Electron you need some means to supply it with 5V. With the LiPo alone you’d need a boost converter to get 5V off of the 3v3 pin.
I’ve been trying out this code for a bit now the past couple of days, but I’m not so familiar with the whole TCP server/sink thing yet, so I’m still reading stuff about it
However the sample server can be modified to look for the BMP header and choose the correct extension.
