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

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.


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 :blush: However the sample server can be modified to look for the BMP header and choose the correct extension.

https://go.particle.io/shared_apps/5acf488479a1de362f0006d7

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).

2 Likes

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.
00001

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.

7 Likes

Looks amazing! :heart_eyes:

1 Like

Sweet!

One giant leap for mankind :slight_smile:

1 Like

But just a small step for @ScruffR :sweat_smile:

3 Likes

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?

Noted.

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.

I’m going to start testing out this library in a couple mins… :slight_smile: Apologies for not giving any feedback in the last 2 weeks, in fact things have been crazy busy for me, so I can finally sit down now and test the uCAM :slight_smile:

1 Like

Hey, just a quick question (I’m probably stupid):

I have the camera all set up and ran the imageReceiver.js file. However, where do I actually find the IP + Port of this server?

Perhaps I’m doing something wrong and am not actually running the server properly - I notice that an ‘out’ was created in the same folder. Is that correct?

I suppose you have got your server connected to a consumer WiFi router which is either connected directly to your ISP or via some other router.
In such a setup your server will probably have an IP like 192.168.#.# or 10.0.#.# but these are not globally unique, hence the Electron cannot access these. It only can access the public IP of your gateway router.
You need to find that and also set up port forwarding as mentioned further up already

If this is not an option for you - as was not for @RWB - you may need to use a service like dynDNS.

1 Like

Yeah that makes sense, I will give these suggestions a try. I unfortunately have no control over the portforwarding process.

In the long run, I probably would not want to continue running a server on my own Computer anyway, and instead indeed do the same thing @RWB did.