Software releases

From edgertronic high speed video camera
Jump to navigation Jump to search

Version 2.5.2

  • Added auto-exposure capabilities.
  • WebUI based network configuration support.

Update file

Update your edgertronic camera by copying the v2.5.2rc32 update tarball file to the big SD card, powering on the camera, and waiting around 7 minutes for the camera to finish updating.

If you are updating from 2.4.1g6 or earlier, you will need to perform a factory reset after the update.

Version details

Build host: linux-vm
Built by: tfischer
Build date: 20220414215459
Build tag: ssc1
Build hash: 7e9aa737
Build version: v2.5.2rc32

CAMAPI documentation

Python class exposing edgertronic CAMAPI via HTTP: v2.5.2rc30 documentation

Release Notes

Improvements since software release version 2.5.1:

  • Auto exposure - Automatically adjusting the exposure (shutter speed) to maintain a correct exposure while the scene changes in brightness (i.e. going from sunny to cloudy). Since the exposure can not be longer than ~1/frame_rate, the user will need to preset ISO, frame rate and lens aperture to allow a correct exposure for the lowest anticipated light level.
  • Improved image quality for SC2, SC2+, and SC2X. These are proprietary changes giving us even more of a competitive advantage. If your use case needs a more detailed description, please contact us.
  • WebUI network configuration - A new tab in pro settings mode allows WebUI based camera network configuration including IP address, DNS server address, and NTP server address.
  • Genlock terminology change - The documentation, WebUI, and camconstants.py enumeration text have been modified to refer to Genlock source camera and Genlock receiver camera. CAMAPI remains backwards compatible.
  • The camera name, if set, shows up in the browser tab. This is helpful if you have multiple cameras; enabling you to identify each camera by mousing over the browser tab. This feature was requested by a customer.


Improvements since software release version 2.4.1:

  • Multi frame rate capture - you can configure the camera to have a slower frame rate for the pitcher wind-up and follow through while having a high frame rate for analyzing the actual pitch. This reduces the time to save a video, the time to review a video, and also creates smaller video files.
  • Background save LIFO - you can choose to save the oldest capture first (FIFO -- first in first out) or save the most recent capture first (LIFO -- last in first out).
  • PocketRadar© support - camera can power the PocketRadar via the USB connect and PocketRadar can trigger the camera. PocketRadar configuration through the camera's web user interface is supported.
  • When you browse to the camera, live view is displayed instead of the settings modal. This change was made because so many edgertronic cameras are now under computer control and when you close the settings modal, it changes the camera state (which can cause the controller computer to get confused).
  • Camera name support - you can assign a human readable name to each camera. The name shows up on the web UI. You can include the name in the notes overlay and in the video file name.
  • Recenter field of view - digital pan and tilt so you can adjust the camera's field of view without having to physically touch the camera. Useful when a camera is mounted in a stadium or on a pole.
  • Rename last video - Allows captured video files to more easily integrate into video analysis software systems.
  • Factory reset a camera by sending a command over the network.

Resolved defects

20210611094523 Factory reset may be required after camera software update

After updating to v2.5.1 or newer from a version v2.4.1 or older, you may need to do a factory reset after the update. The camera remembers all your customized camera settings during the update process. Somehow one of those settings is not being accepted by v2.5.1 or newer. Note that a factory reset will erase any custom interfaces file with a fixed IP address other than 10.11.12.13, which may cause you to temporarily lose your connection to the camera until you figure out which address is being used by the camera.

This is due to unmodified default configuration files being saved which keeps newer software releases from using their updated default configuration files. The defect was fixed by deleting unmodified configuration files before the new software runs, forcing the new software to install its default version of the configuration file. The issue caused problems due to an update to the lighttpd web server configuration file to work around an ipad security change.

20220413093412 Auto exposure image quality problem

Around one out of ten times after a full camera calibration, the image quality is bad due to an auto exposure defect. Thanks Nick and Brian for reporting this defect. The defect existed in v2.5.1rc1 through v2.5.1rc31. You can work around the defect by forcing another full camera calibration (such as a small change to the ISO value).

20220214111512 Cross-Origin Resource Sharing (CORS) not working

Software release v2.5.2rc27 broke CORS, which was fixed in v2.5.2rc28. The camera now ships with a CORS test file that you can download from the camera via http://11.12.13/static/host/cors.html . The test file needs to be first downloaded to your computer, then use your browser to open the local cors.html file that you downloaded. Enter the edgertronic camera's IP address you want to test and press the Run CORS test button.

20211023094302 certain camera settings did not capture any post trigger frames

You always have to capture at least one post-trigger frame, meaning the trigger frame. Adjusted the calculation for pre-trigger, post-trigger1, and post-trigger2 frame count so there is at least 1 post-trigger1 frame captured.

20211030140344 total saved videos isn't updated in the video overlay

If you have the total saved video count in the notes overlay in review before save, the video count wasn't being updated as you saved videos. It did catch up once you went back to the running state.

20211107115832 CAMAPI rename_last_video() does not expand parameters

If you pass in a filename like Boddy_K_999999_Bullpen_Seattle_&d_&T_&a_&b_99.2MPH the filename parameters are not properly expanded. Defect was fixed by properly expanding parameters.

SDK API changes

  • New configuration dictionary key 'auto_exposure' whose value is an enumeration. This key is supported by CAMAPI methods configure_camera() and run(). Since auto-exposure effects the video frames as they are captured, trying to change the the auto_exposure key via CAMAPI methods reconfigure_run() and configure_save() has no effect.
  • CAMAPI method rename_last_video() now uses POST instead of GET, accepts a dictionary as a parameter and returns a dictionary, which included an 'err' key with CAMAPI_STATUS_* indication. This allows both the actual filename used to be returned along with a outcome indication.
  • hcamapi enhancements
    • added auto exposure to METADATA_FILE_LOOKUP_TABLE. It will be added in the next release candidate (rc).
    • added up to 3 retries when sending a command via _fetch_target. This handles connection errors, which were keeping the endurance tests from running long term.
    • made the hcamapi module more python3 friendly.
    • improved the API documentation for reconfigure_run(), trigger(), configure_save(), and rename_last_video().
    • added support for net_get_configuration(), net_set_configuration().
    • API _parse_metadata() now uses the terms genlock 'source' and genlock 'receiver'.
    • updated fetch_remote_file() and display_remote_file() to use python module requests, instead of urllib.

Developer changes

  • Added example HTML and python files showing how to add content to the WebUI. The files can be retrieved from the camera via http://10.11.12.13/static/sdk/app_ext.
  • In the metadata file generated for each saved video, the line in the text file that refers to the genlock setting value now uses the terms source and receiver. If you use the metadata file parser in hcamapi.py, it has been updated to handle these terms. If you created your own metadata file parser, you need to update it to handle the new genlock setting value terms.
  • After running v2.5.2, when you do the next update, the camera will remember the previous software version prior to doing an update. This feature will be used for the anticipated, but not yet implemented, WebUI based camera software update support.
  • Added remove recovery URL http://10.11.12.13/factory_reset_keep_ip which allows a work around if you find after the update the camera needs a factory reset, but you don't want to lose the network settings.
  • Enabled busybox nslookup.
  • When networking is reconfigured via WebUI, we reboot the camera if the IP address changes. This should not be necessary. There is currently some dependency on GStreamer (which isn't using IP networking) that fails when the IP address changes. This issue should get resolved when the camera is upgraded to GStreamer 1.14 in a future release.
  • The lighttpd web server now marks the necessary responses with Access-Control-Allow-Origin to allow cross-site support.
  • When a software update fails, the lighttpd web server provides information on what went wrong. This contents of this information has been expanded to enable better customer support.
  • General improvement in logging python errors when invoking CAMAPI. In theory you should not be able to invoke a python error in the base camera code, but if you find as a defect, providing a helpful report will be easier.
  • Update tarball filename now includes the human readable software version number.
  • The /image2 URL to grab the current JPG live view image was changed to a new URL /images/image2.jpg. This change was done to ease software development, but had the unintentional consequence of breaking some host applications.
  • 83 files changed, 5,100 insertions, 1,937 deletions

Known defects

The following is the list of known defect in the version 2.5.x releases. [1]

20220415111422 Setting the DNS server IP address via CAMAPI net_set_configuration() is broken

requested_dns_server and dns_server keys not handled properly in dictionary passed to net_set_configuration().

20190302135422 SC2 SC2+ SC2X pretrigger frame count inaccurate on when the pretrigger buffer is not full and a trigger occurs

If you trigger a SC2, SC2+, or SC2X camera before the pretrigger buffer fills, the metadata file will have an inaccurate number for the frames captured before the trigger event. This also effects review mode.

201412161349 Multishot Genlock buffering can get out of sync due to power cycle or selective save

No fix defect -- there are no plans to fix this defect.

If you are in the middle of a Genlocked Multishot sequence and power cycle one of the cameras, the buffering will be out of sync once the camera is powered back on. Until the cameras configured for genlock talk to each other over the network cable, there is no way to resynchronize which multishot buffer is being used.

Work around: Power cycle all cameras that are configured and cabled for multishot and genlock.

Similarly, if you are in the middle of a Genlocked Multishot sequence and decide to save your video set, you cannot just press the save button on the genlock source camera's GUI since only the videos on the genlock source will be saved.

Work around: you must press the save button on the genlock source and all the receiver camera GUIs.

201409120935 Updating camera fails if there is a space in the update tarball filename

If you download the update tarball more than once, some operating systems put a space in the file name (e.g. " (1)" so the file being downloaded will have a unique filename. If you use the file with the space in the filename, the update will fail. To work around the defect, remove the big SD card, delete the file with a space in the filename and store the original file on the big SD card. The camera will then update correctly.

201409091802 Cancel trigger at the end of capture misbehaves

No fix defect -- This is really not a defect.

On occasion, if you cancel the trigger just as the post trigger capture buffer is being filled, the camera will calibrate then save the video data instead of properly handling the cancel.

Work around: This is a race condition. The user thinks the camera is still capturing data when they press cancel, but in fact the camera has already switched to saving the captured video. Simply trim the video to get back to filling the pre-trigger buffer.

201408271324 Genlock false triggers

No fix defect -- there are no plans to fix this defect; the hardware design doesn't support any means to fix the issue.

This defect only occurs when using the Genlock feature with multiple cameras and a genlock cable.

Plugging in genlock cable may trigger both genlock source and receiver cameras. Unplugging genlock cable may trigger both genlock source and receiver cameras. Powering off a genlocked camera may trigger any other connected cameras.

Work around: connect all genlock cables before powering on the cameras.

201312111624 File timestamp is in GMT

No fix defect -- there are no plans to fix this defect.

The camera was intentionally designed to use GMT for the timezone when saving video files. Some might consider this a defect (issue #182).

As of 2.4.1 you can create your own filename pattern and not use seconds since 1970 in GMT timezone.

201312021613 Browser forward and back buttons may change camera settings

No fix defect -- there are no plans to fix this defect.

If you browse to another site and then use the browser back button to return to viewing the camera, your camera settings may have changed.

Work around: either don't browse to another web site or don't use the back button when you do; simply browse to the IP address of the camera.

201311041114 Playing last recorded video can fail in rare cases

No fix defect -- there are no plans to fix this defect.

The camera will automatically switch which storage device is used when the current storage device fills up and another, non-full, storage device is available. You can not play the video recorded right before the switch occurs since the active storage device has changed.

Work around: You can remove the storage device and properly play the video by retrieving the video file from the non-active storage device.

201311101454 CAMAPI does not detect new space on mounted storage device

No fix defect -- there are no plans to fix this defect.

CAMPI handles changes in storage status using an interrupt scheme (mdev). If your SD card is full and you telnet into the camera and delete some files, no event occurs, so CAMAPI doesn't detect there is now room and the memory full message is displayed.

Workaround: after deleting the files, remove and reinsert the storage device to create a change in storage status event.

[1] Naming convention for the 'Defect numbers' are in the format YYYYMMDDHHMMSS

Software release images

Software release file format

Each software release comes in two formats:

  • The file for performing a normal update (called a tarball, where the filename starts with sanstreak_update and ends with the file extension .tar). To update the camera software, simply put the tarball file on the SD card, install the SD card in the camera, and power on the camera.
  • There is also a recovery file which is used if you want to directly image the micro SD. The recovery file starts with sdcard and ends with the double file extension .img.zip. You need to follow a specific set of steps to properly image the micro SD card.

Official software releases

Sanstreak releases software when we have a good collection of new features and the software passes all of the hundreds of automated and manual test cases. Most people should be running the latest software release. We do make older official software releases available if case you need to downgrade your camera. You can be running any official release and upgrade or downgrade to any other software release.

Release
Name		 Normal
Update
File		 Recovery
File
v2.5.1rc20 normal recovery
v2.5.1rc19 normal recovery
v2.4.1g6 normal recovery
v2.3.1g1 normal recovery
v2.2.2g6 normal recovery
v2.2.1rc8 normal recovery


Older releases

All cameras can safely downgrade to version 2.5.1, 2.4.1, 2.3.1 or 2.2.1. Software versions older than 2.2.1 have been removed due to hardware changes that make older versions incompatible with some cameras.

After downgrading the camera, a factory reset is recommended.

Anticipated features

Let us know what features you would like to see added to the edgertronic high speed camera. Here are some requests we have received:

  • Detect when an SDXC / eXFAT card is installed and notify the user it needs to be reformatted as VFAT file system.
  • Pretrigger percentage greater than 100%. This allow devices, like radar, that can trigger the camera after the action has occurred to avoid saving post action frames.
  • Over the network software update - allow upload of an update file from the user's computer
  • Support Design rules for Camera File system
  • Usability - when using CIFS, don't check for free space so often
  • Update Open Source packages
  • Performance tuning / SPI overhead investigation
  • White balance, focus aid and exposure histogram
  • Camera auto discovery on the network
  • User name and password to control who can browse to the camera
  • Add support for <video> tag in HTML served up by the camera
  • Add support for camera telling web U.I. when a status change occurs
  • User supplied gamma correction table.
  • Image based triggering
  • When one camera on the local network is triggered, have it use multicast network trigger to trigger the rest of the cameras on the same local network. Available now using User Added URLs facility.
  • Support rotating the camera image 90 degrees so the camera can take highest frame rate capture of vertical images.
  • Node.js binding for CAMAPI (python and .NET binding already available)
  • Enhance multi-rate capture where the physical trigger button can be used to switch from post1 capture rate to post2 capture rate.

Requested features

  • Allow background triggers while in review before save. Allow captures to be discarded after saved in review before save.
  • Having the camera POST its status (namely when a file is done encoding) to a user specified HTTP address. This may be possible using the User Added URLs facility.
  • Sound based triggering - This will not be supported.
  • Halogen color temp setting - Because of the decreased use in halogen lighting this feature is less useful over time.
  • Multi-trigger in multi-shot capture - Trigger capturing the next video while the current video is being captured, with no frames being dropped.
  • Extend CAMAPI review_frame() method to return the actual frame image instead of the status
  • User added URL that copies videos and metadata from SD card to a network computer using FTP.
  • Allow genlock signaling to just trigger a camera. Imagine an environment with three genlocked cameras focused on the local event activity and a forth camera taking an overview video that also covers before and after activity. It would be nice to simply use the trigger signal from the genlock source camera.
  • Enable audio recording
  • Adding wireless client in the camera
  • UDP discovery
  • Trackman ready physical extension for the camera
  • A submillisecond time integration with tracking devices
  • Background save for selective save
  • URL factory_reset3 which performs a factory reset on everything but the /etc/network/interfaces network settings.
  • Trigger delay compensation - camera setting to compensate for the delay between when an event occurs and delay in the system that is generating the trigger. For example, a human's response time is pressing a trigger button after seeing lightning is around 400 ms. The implementation would be to increase the pre-trigger time by the trigger delay compensation, then when saving discard all the frames from the point in the capture that is trigger minus the trigger delay compensation value.
  • Enhance CAMAPI selective_save() method to allow specifying a frame dropping pattern as the video is being saved. The frames to be dropped would be specified via a list of (starting_frame_number, save_ratio, ratio_slope) tuples. Imagine a captured video of a baseball pitch at 700 fps. Assume the capture duration is 3 seconds, with 1.4 seconds being the wind up, 0.7 second pitch and 0.9 seconds of follow through with the playback frame rate set to 30 fps. Then the wind up could be saved at half playback speed using 60 fps (meaning of the 980 frames saved in the first 1.4 seconds at 700 fps, only save 84 frames, or dropping 11.6 frames for each frame saved), make a transition from 60 fps to 700 fps, save the pitch at 700 fps, then again transition back from 700 fps to 60 fps.
Retrieved from "https://edgertronic.mywikis.wiki/w/index.php?title=Software_releases&oldid=5491"