uCAM III-application (including TCP- and HTTP transfer)

Got it.

I will test it out real quick.

UPDATE! @ScruffR

It’s working fine now. No more crashing from outside under the sun pictures :slight_smile:

Good work!

For anybody following along, the web page served by the Photon looks like this now:

You can adjust the Time.zone() to fit your time zone and have correct timestamps.

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.

1 Like

@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 :slight_smile:

Thanks for the pictures, as you stated @RWB , a wide-angle lens indeed is necessary for my project

Wide angle lens arrived today.

I tried it out and it provides a much wider viewing area than the stock lens as expected.

Picture quality seems slightly better to me.

I think most people would prefer this wider angle view vs the stock lens.

I’m just finishing the PoC for the TCP transfer.

@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 :blush: 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).

1 Like

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

1 Like

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.


Looks amazing! :heart_eyes:

1 Like


One giant leap for mankind :slight_smile:

1 Like

But just a small step for @ScruffR :sweat_smile:


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 :wink:

1 Like

@ScruffR Did you get the Electron picture upload code working?

Uhm, yes. That was when I posted this

Or am I misunderstanding your question?

I figured you were just posting your progress of getting it working but you didn’t say or include a link with new code so I figured it was not ready yet or maybe it was something @Vitesze was paying you to create.

I see your example code folder now I took a look :slightly_smiling_face:

So to use your example code on the Electron you just have to run ImageReceiver code in Node and then the Electron the server IP via setting a Particle variable that holds the server IP?

Does the Image Receiver code just save the image data to file or display it? I have never used Node before except to run the Particle CLI application.

Actually the link was there already, since the code hadn’t changed between post #50 of this thread and my Electron image post, I didn’t see need to provide the same link again, sorry.

I’ve now already published v0.0.3 of the lib to the Library Repo.

I tried to put all the required info into the comment block at the top of the sample, but being so involved in the topic I might have assumed too many things to be clear.

So I’d be greatful if you could point out things that aren’t clear enough to make it understandable to as many people as possible.

That’s a note I can also add in the comment, but as with the (missing) link also that info was provided already in my earlier post

This out folder will be created by the NodeJS server inside its own directory.

One note about a point that might not be clear but is beyond the scope of the library and hence won’t be added to the comment block:
Since the Electron is not connected to your LAN it will have to access the NodeJS server from outside of your LAN and hence you need to tell it your LAN’s public IP address and configure port forwarding on your primary router to forward any outside requests to the local IP of your server. The local server will listen on port 8124 but your “public” port does not need to be the same - the port translation is also to be set up in your router.

No problem, I didn’t have any time to test it until now anyways but I am looking forward to giving it a go!

This whole camera thing got me to try out Motioneye OS security camera software on an old Rasberry Pi 3 & Raspberry Pi 2 camera I have had sitting around for more than a year now and I’m amazed at how well it works in full HD.

No problem, I’ll give it a try soon and see how it works out and provide feedback if something is not clear from an amateurs point of view.

Did you do any testing with cellular data consumption for the full-size jpg image transfers?

@Vitesze Have you got this working yet on your end?


I’m using my cellphone as my WiFi hotspot and it does not have port forwarding options built into it so sounds like I will need to test this out somewhere I have access to a router I can port forward. Thanks for noting this.

That’s an unfair competition :wink: RPi’s are playing a completely differrent league.

The used cell data is pretty much the same as the image file itself plus ~5-10%
The image is sent in junks of 512 byte which are wrapped in the UDP “envelope”.

For testing this might not be an option, but if this happened to be a permanent solution then dynDNS might be an option.