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

@Vitesze I had a chance to take a look at that uCam2 library that was supposed to work on the Photon.

I altered this library removings parts that we don’t need for now.

The code will attempt to take a snapshot and then a full picture when you pull pin D1 high to 3.3v so try that and watch what the serial output says about successfully taking the picture or not.

If it says it successfully takes the picture then we will need to change the code where attempts to send the picture data to a IP address so it does what we want it to do.

1 Like

Thanks! Will look at it today :slight_smile:

I have written a completely new uCamIII library which should also support uCamII (just some advanced functions aren’t supported by the II).
One major difference to the Arduino uCamII library is that mine is not tied to any serial interface but can be used with any of the HW interfaces and ParticleSoftSerial too.

If you could try the uCamII and the Webserver example on a Photon, I’m open to suggestions how to improve it.
Electrons can’t easily be used as Webservers (due to “non-routable” local IP), so currently on Electrons the demo can only stream the taken image to USB Serial where you need to dump the stream into a file (or any other sink) to further process it.
Next step will be a TCP transfer sample that can also be used to receive the data wirelessly from an Electron.

5 Likes

Great work!

This can finally be a reality :slight_smile: @Dave

image

I received the camera also and its images are good enough to be useful.

I’ll give your code a try on the Photon.

What I’m wondering is if we could store the picture data on an Electron in a variable array instead of pushing it to a SD card for storage. Even if there is enough room to store only 1 picture that would be fine, I know memory is limited.

Then we could use @rickkas7 FTP library to upload that picture data array to an FTP server which I know works because I’ve tested it in the past with success.

What are the possibilities of this?

2 Likes

I had a look at @rickkas7's FTP endeavour but his assertion about FTP being a "bitchy" protocol with lots of overhead, made me decide to rather go for a simpler demo more along his line of this

or any other TCPClient -> node server route.

My sample just stuffs the image in a static array of 160x120x2 = 38400 byte (max size for raw images produced by uCamIII - even 640x480 JPG won't be as big as that).
But with bigger projects that might not be the way to go.

3 Likes

@ScruffR Just tried the Photon demo and it’s really simple and works every time! :tada::camera::tada:

Really nice that this can be setup and you can just call the function remotely to have the picture taken and displayed on a local browser.

Less overhead on the Electron would be ideal, although I’m not sure how much overhead we would be talking when just uploading these images using his FTP library.

Looking forward to trying your Electron sample program :slight_smile:

I just take Rick’s word for it but IIRC in his tests he had a 50-60% overhead due to the permanent handshaking.

1 Like

That’s looking great!

Can’t test for myself as I am still waiting for my Photon to arrive, but I’m thrilled and can’t wait to test things on an Electron as well.

I’m not really too fussed about some overhead; the small images should keep the amount of data pretty low anyway.

So for the Electron example will Node JS be required to receive the pictures sent by the Electron?

The only thing I think needs added to the web interface options is the ability to adjust the brightness and contrast for when the image gets washed out due to lighting conditions.

I’m also curious if there is a way to have the image auto-update automatically in the web browser at a set frequency like every 10-20-30-60 seconds or so?

@ScruffR Here are some issues I’m seeing when testing the code + camera.

It always works inside the house or in lower light levels.

When I point it towards an outside facing window where the picture has the sun and is really bright when I try to take an image JPG 640 x 480 image the Photon it will try to start taking the picture and the blue LED will light up but the Photon will then go to blinking RED on the status led and eventually restart the Photon.

If I take the outside picture in the lower resolution 320 x 240 JPG it works fine but when I switch back to 640 x 480 and take bright pictures the photon will send the red SOS panic LED again for some reason.

If you take the kit outside in bright sunlight does the same thing happen to you?

The photon was not in the direct sunlight but shielded from direct sunlight.

I switched wiring and it still happens.

Also is there anywhere Particle Process should be called during the image transfer process because I’ve seen the Blue flashing status LED switch to Green flashing LED when trying to take bright outdoor pictures for some reason.

It’s weird this does not happen inside when the light is not as bright.

The 320x240 JPGs will be between 10k & 20k depending on the image and its compressability.

I haven't tried "overly" bright images, but since the content of the image influences the compressability it might be that my static buffer gets too small for images that won't compress well.
But since the buffer is not part of the library but does get provided to the lib by the user app, you can increase the size at will.

I guess so, but nothing is fix yet, I've not yet started implementing the sample.

I'm not going to add an auto-update feature, but may consider adding the CBE settings in the sample, but not before the TCPClient sample.
You can extend the demo as you wish - the library provides the functions to change the settings.

Good to hear! I'll play with the buffer size and see what happens.

I wonder if there is a way to just send the picture data to an email address? No idea if that's easy to do or not.

Makes sense. Getting this running on the Electron was the initial goal anyways.

The outdoor pictures did seem to adjust to the brighter images just fine with the images I got at 320x240. I'll do some more testing once I increase the buffer size and get some outdoor 640 sized images.

Keep up the great work! :wink:

1 Like

@ScruffR When changing the image buffer size I just need to worry about this image buffer line correct?

I’ve tried changing this to 56960 and 46960 and the compile but the program does not run correctly.

I’m assuming I need to increase by a certain number for this to work correctly with other code maybe?

What would you recommend as a buffer size that should work but not take up more memory than needed?

You are correct about the imageBuffer but what does this mean?

This is a rather vague symptom description :wink:

I'd have to do some tests.


Update:
I've now added the contrast, brightness and exposure settings and made the page "remember" the last settings.
But I couldn't reproduce your crashing even with a rather bright picture

Are you using a uCamIII or uCamII?
I'm not sure whether the uCamII supports contrast/brightness/exposure and the JPG compression might be a bit weaker than on the uCamIII.

1 Like

When I change the image buffer size to 46960 the photon does not take pictures.

If I increase to 56960 the Photon breathes white. Do you see the same thing?

Sweet! Remembering the last settings is helpful.

Happens every time I try an outside bright picture for some reason, this is on and off a breadboard.

I'm using the same camera that was sent to you, the ucam3.

1 Like

I tried the new library sketch and it’s working great.

I still can not take pictures out the outside without the Photon going into flashing red SOS mode and then restarting. If I switch to 320x240 jpg size mode it works perfectly.

I found an auto refresh add-on app for Firefox browser so now it automatically updates the picture in the browser every 15 seconds automatically which is nice.

The only thing I found myself wanting was to know what time the picture on the webpage was taken. Like a timestamp below the image and above the Download Image Link.

This is pretty cool.

The only thing it leaves me wishing for is a sharper image :slight_smile:

That would be easy to add, but I want to leave some puzzles for you to solve :wink:
The web page is all there to add some <label> tag and when you extend the P(script) and the respective snprintf() that uses it as format string and populates it with the settings, you just add the timestamp there and there you are.

You can turn the lense to adjust focus it that'd be the reason.

I'll try to reproduce your SOS panic. How many blinks do follow the SOS?

BTW, there is a commented SerialLogHanlder line at the top of the sketch. When you uncomment that, you can get some trace output via USB Serial that might help narrowing down the problem.
The extra time for the logging might break the transfer due to timeouts but the SOS panic should happen before that, so the trace output would be helpful.

Cool, the date and time is not a big deal so I’m cool with the way it is now.

I emailed Arducam to ask if they had any higher resolution camera modules that work on the same commands that the uCamIII does. Doubt they have any but I figured it was worth asking.

I will see what I get on the Serial Log output next time I give it a try. I’m assuming it’s an image size and buffer being not large enough issue.

Yup, with logging on, with 46960 you get this info

0000000520 [hal.wlan] TRACE: Free RAM connect: 7720

~7KB is not a lot when you start off before the Webserver is instantiated.

With 40960 you do get this

0000000521 [hal.wlan] TRACE: Free RAM connect: 13720

So you haven't got a lot of room to play with to increase the buffer, but as I'm still unable to make my 640x480 high dynamic JPGs any bigger than ~32KB I'm stumped by how you do it.
Maybe the log will reveal how big your images actually get.

Have you played with different CBE settings?
Do they have any impact on the image size?

However, since the uCam delivers JPGs in chunks of max 512 byte at a time, splitting an image up and transfer it slice by slice is an option - just not for the example app.

    if (imageType == uCamIII_SNAP_JPEG)
      for (int received = 0, chunk = 0; (received < imageSize) && (chunk = ucam.getJpegData(&imageBuffer[received], 512, callback)); received += chunk);

The actual intent if the library is to enable users to incorporate the uCam into their own project, not to deliver a fully fledged solution.
The examples should just be a show case of what's possible and help getting started :wink:


I've rearranged the select fields a bit and while doing so I've also incorporated your image timestamp :wink:
https:/go.particle.io/shared_apps/5ac87e29fd44eba92e0002fe
Latest revision: Particle Web IDE

1 Like