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

Yea that wide view lens makes a big difference :eye:

Is your company willing to pay for @ScruffR to create code that pushes pictures to an FTP server assuming he is up for the job?

@RWB, @Vitesze, I wonder if the entire part of this post regarding the uCamIII shouldn’t be split off to its own topic. As it is, the title of this topic really hides all this goodness!

The snack corner can be his :stuck_out_tongue_closed_eyes:

But yeah, at this point since it’s a pretty complex topic we’re tackling, so it’s up for negotiation.

I will adjust the topic title. I agree, this topic probably contains some of the most useful chain of posts and information on any microcontroller-camera application.

1 Like

Did anyone ever get this working for FTP?

We are running image transfers to google cloud storage.

1 Like

Can you share the code your using to send files to Google storage?

Our working solution is part of a commercial application, so I’m not able to share it openly. If someone is interested in a private collaboration then the business would consider the situation. Just fire me a message if that’s the case.

That being said, we are open to publicly collaborating on an approach using Google IoT Core as an alternative method to conduct the upload. I think this would benefit us as well as others, but the memory constraints make this difficult.


Given the time that has passed since this thread began, is this still be best option for sending and occasional photo from the Electron to the cloud? I have a potential use case that is common with several mentioned, I have a PIR sensor which, when it detects movement, would send a photo. I understand that there are significant limitations on the speed at which this can be done and on the impact it would have on the data caps but, would like to see if I could get it working first.

The long term approach would be to use a Pixy2 and just send information about the picture (such as “two people walking”) but, in reading the state of the art on these machine vision cameras, it seems like this is still a ways out.

@ScruffR, yes, I have been searching the forum but, have not found anything as promising as this thread.



1 Like

The Ucam camera works and has great low light capability.

@scruff has code that uploads the images to a server already, so it is a working reliable solution.

The only desire would be to use a higher resolution camera, but that increases file sizes and data needs also.

@chipmc, there isn’t a lot that could change. The fundamental techniques will stay the same for years to come and the hardware limitations on these devices will also not allow for much improvement AFAICT.

New hardware (like Pixy2) may open new approaches in future but that’s not an option yet.

1 Like

@ScruffR I tried getting 1. the server running and 2. the .ino file running and ran into many problems. the server does not output the IP and port upon startup and hangs at this line: net.createServer(function (socket) and for the firmware upon calling snap I get a return of -1 and it looks as though it is a sync error? I used the uCam-lll on an electron and a photon.

Also would it be hard for you to edit this code to send to a Google Cloud Platform via sending the image buffer upon calling a particle function and then the google cloud platform can receive the image buffer and process the image there? I am happy to do the Google Cloud Platform and submit it as a PR on your github repo


I’d need to have another look at your issues, last time I used this library everything worked for me.

Yup, that’s beyond my scope of this library and the samples provided as PoC with it.
But if you can file a PR with some setup walk-through I’d be gladly merge and upload a new version.

1 Like

Okay, what version of node did you have this set up for?

I’m running node v8.9.4

That’s normal, since in order to report the address of the remote client that client needs to connect first :wink:
You can try the server independent of the uCamIII library.
e.g. via telnet <IP of your host computer> 8124 then you should see the IP of the device you were running that command from.

1 Like

Considering I’m on a corporate network and am not able to touch any router settings (e.g. portforwarding) to receive images locally on my PC, what alternative way can be recommended to have an Electron take and send photos somewhere else? It can be a paid service.

Let me jog your memory. We had discussed a solution in that PM thread :wink:


Any idea why on a Boron LTE the tcp sending would fail after package 11?

Below are the trace logs. It always gets to package 11 and then nothing, it just hangs.
The image arrived so far is valid. Sending it through serial is no problem, the image arrives in full.

0000032771 [app] TRACE: getJpegData
0000032772 [app] TRACE: sendCmd
0000032773 [app] INFO: sendCmd: AA 0E 00 00 07 00
0000032821 [app] INFO: Package 8 (506 Byte) -> TCP x.x.x.x:port
0000032824 [app] TRACE: getJpegData
0000032825 [app] TRACE: sendCmd
0000032827 [app] INFO: sendCmd: AA 0E 00 00 08 00
0000032874 [app] INFO: Package 9 (506 Byte) -> TCP x.x.x.x:port
0000032878 [app] TRACE: getJpegData
0000032880 [app] TRACE: sendCmd
0000032881 [app] INFO: sendCmd: AA 0E 00 00 09 00
0000032928 [app] INFO: Package 10 (506 Byte) -> TCP x.x.x.x:port
0000032931 [app] TRACE: getJpegData
0000032932 [app] TRACE: sendCmd
0000032933 [app] INFO: sendCmd: AA 0E 00 00 0A 00
0000032981 [app] INFO: Package 11 (506 Byte) -> TCP x.x.x.x:port

And then after about 60 seconds:
0000087671 [gsm0710muxer] ERROR: The other end has not replied to keep alives (TESTs) 5 times, considering muxed connection dead

This might be a Boron connectivity problem, so I have also raised this as a separate thread under Boron LTE connectivity problem

1 Like

@RWB and @ScruffR,

Am, finally, getting the time to pick up this thread and @evk02 is already on the point I was going to ask - will this work with the Boron? Does moving from 3G (UMTS) to LTE (CAT M1) help or hurt us?



It worked on the Photon that I tested it with.

I don’t see any reason why it wouldn’t work over cellular on a Boron but we need to live that to somebody who knows what they are talking about @ScruffR

The only thing left to be desired is a camera with better image quality.

There may be a better serial camera on the market now so I would search around and see if you come up with something with a higher resolution & sharper image.

I haven’t tried a Boron but I guess LTE Cat M1 is considerably slower than 3G.

That issue would be even more prominent with a higher res camera.