Software releases

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

Version 2.5.3

  • Better user experience when using a tablet to control the camera.
  • Improved accuracy in trigger time value. First set of measurements showed +/- 10 ms or better of accurate time when using stratum 1 NTP server.
  • Manual save mode for easier integration into a larger data acquisition system.
  • Detects and reports via webUI if an unsupported exFAT file system formatted storage device is installed.

Update file

Update your edgertronic camera by copying the v2.5.3rc31 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: 20240304145102
Build tag: ssc1
Build hash: 6dd23f0a
Build version: v2.5.3rc31

CAMAPI documentation

Python class exposing edgertronic CAMAPI via HTTP: v2.5.3rc27 documentation

Release Notes

Improvements since software release version 2.5.2:

  • Better settings layout on iPad to get rid of the extra whitespace. This resulted in a minor reordering of a couple of settings in the Options tab.
  • Changed reported trigger time from an integer to a floating point number. Tested the accuracy of the reported trigger using a stratum 1 NTP server connected on the local network. Improved how trigger time is captured to compensate for the non-real-time nature of the Linux operating system.
  • Improved memory BIST reporting.
  • Manual save mode for easier integration into a larger data acquisition system.
  • webUI detects and reports if an unsupported exFAT file system formatted storage device is installed.
  • The webUI help system now points to internet edgertronic wiki instead of cached wiki in camera.

Resolved defects

20241101091823 Slow DHCP server can cause multicast network trigger to fail

If the camera's multicast network trigger daemon is started before a DHCP address is assigned the daemon will not detect multicast triggers. The issue was due to the special network route needed being lost when the new address is assigned.

202309051411 Passing a parameterized filename via multicast trigger truncates filename at the ampersand character

If you include in the multicast trigger UDP packet a filename like behind_home_plate_inning_1_pitch_27_&T the actual file saved will be behind_home_plate_inning_1_pitch_27_.mov.

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.

This defect was resolve in release 2.5.2rc33, which wasn't widely distributed.

20220909151902 Camera doesn't properly handle the network gateway setting

This defect goes to show if you don't test properly, it likely won't work. Hope is not a successful develop strategy. I didn't have a complex enough network setup to test the gateway functionality. Now I do. This defect has been resolved.

202301083425 Camera wasn't properly reporting temperatures below freezing

When the camera internal temperature dropped below 0 Celsius, the calculation of the negative value wasn't done properly. This defect has been resolved.

20230214082349 CAMAPI cancel() doesn't propage changes made using reconfigure_run()

When in review-before-save mode, if you change the camera's settings via the webUI (or reconfigure_run()) those changes do not properly propagate to the future captures when you invoke the CAMAPI cancel() method. This defect has been resolved.

20230227173428 WebUI overclock setting not being handled properly on an SC2 camera

There was a javascript error when running with an SC2 8GB camera. This defect was introduced in a beta release, so most customers were not effected by the issue. This defect has been resolved.

SDK API changes

Developer changes

  • New manual save mode.
  • CAMAPI get_captured_video_info() trigger time is a floating point number instead of an integer and includes the anticipated filename that will be used unless overridden (e.g. via CAMAPI [selective_save() parameter). If the user parameter was set, then get_captured_video_info() returns the user parameter as well.
  • Metadata file reports trigger time as a floating point number instead of an integer.
  • Better logging of all allowed values when CAMAPI run() is invoked.
  • The update tarball is moved to the SD card installed directory instead of being deleted.
  • Potential backwards compatibility issue for software reading metadata files. The trigger time is now a float instead of an integer.

Known defects

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

20231223103452 Overlaying text and graphics causes crash for very small image heights

If you set the vertical resolution to 96 and enable all overlays, the camera software crashes and requires a factory reset to recover.

20231005074253 Spurious Genlock Error reported when camera is properly genlocked

Occasionally a Genlock Error is incorrectly reported by the camera properly configured as a genlock receiver. The captured video is correct.

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 ' ' character 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.3rc31 normal recovery
v2.5.2rc32 normal recovery
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.2, 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. All documentation for all software releases remains available.

Camera model SC1+ will not work on software release prior to 2.5.3.

After downgrading the camera, a factory reset is recommended.

Software release repository

You can find all software releases at:

In addition to the releases, there is a software release schema JSON file and a JSON file containing all the information about the available software releases.

Schema for describing available releases

The edgertronic-available-updates-schema.json file describes the format of the edgertronic-available-updates.json file. It is used with the jsonschema python library to valid the available updates file.

Available updates

A release is a tested edgertronic camera software update. We make other software updates available, such as beta releases, which you should not use. Occasionally I go and delete all the old updates that are not tested releases. I will also delete a previous release if it is causing too many customer support calls. It should always be safe to back rev - use an older release than the version currently running on the camera.

The edgertronic-available-updates.json file contains the following information:

  • last_update_epoc: an integer indicating when the file was last updated. This is in epoc format to allow easy comparision on which of two files is the more current.
  • current_release: string indicating the release version name for the recommended release you should be running on all your edgertronic cameras.
  • releases: dictionary (object in JSON terminology) containing a dictionary for each release.

Each release is a JSON object who name is the release name and the properties include:

  • state: string that is one of released, beta, internal_use_only, or broken.
  • release_date: Human readable date string in the format MMM DD, YYYY.
  • size: integer size in bytes
  • md5sum: hex string encoded value starting with 0x.
  • description: Human readable string
  • release_notes_url: URI pointing to the human readable release notes.
  • download_url: URI pointing to the update tarball file.

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:

  • 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 instead of using 1 second polling
  • 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
  • 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/w139/index.php?title=Software_releases&oldid=5751"