Difference between revisions of "Software releases"

From edgertronic high speed video camera
Jump to: navigation, search
(Older releases)
Line 1: Line 1:
{{Software release version 2.4.1}}
+
{{Software release version 2.5.1}}
  
 
{{Known defects}}
 
{{Known defects}}
Line 5: Line 5:
 
= Older releases =
 
= Older releases =
  
All cameras can safely downgrade to version 2.3.1 or 2.2.1.  Software versions older than 2.2.1 have been removed due to hardware changes that make older version incompatible with some cameras.
+
All cameras can safely downgrade to version 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.
  
 +
* [[Software release version 2.4.1]]
 +
** Released: March 24th, 2020
 
* [[Software release version 2.3.1]]
 
* [[Software release version 2.3.1]]
 
** Released: Jan 4th, 2019
 
** Released: Jan 4th, 2019
Line 36: Line 38:
 
* Support [https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_system Design rules for Camera File system]
 
* Support [https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_system Design rules for Camera File system]
 
* Usability - when using CIFS, don't check for free space so often
 
* Usability - when using CIFS, don't check for free space so often
* URL supporting remote factory reset
+
 
 
* Update Open Source packages
 
* Update Open Source packages
 
* Performance tuning . SPI overhead investigation
 
* Performance tuning . SPI overhead investigation
Line 51: Line 53:
 
* Support rotating the camera image 90 degrees so the camera can take highest frame rate capture of vertical images.
 
* 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)
 
* Node.js binding for CAMAPI (python and .NET binding already available)
* Method using a URL to cause the camera to do a factory reset remotely.
 
  
 
= Requested features  =
 
= Requested features  =
Line 57: Line 58:
 
* Allow background triggers while in review before save.  Allow captures to be discarded after saved in review before save.
 
* 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 [[Extending edgertronic capabilities - Extending edgertronic camera functionality|User Added URLs]] facility.
 
* 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 [[Extending edgertronic capabilities - Extending edgertronic camera functionality|User Added URLs]] facility.
* Add a persistent setting field to input a name for the camera. Display as webpage title instead of “Edgertronic” and anywhere else appropriate.
 
 
* Sound based triggering - This will not be supported.
 
* 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.
 
* Halogen color temp setting - Because of the decreased use in halogen lighting this feature is less useful over time.

Revision as of 17:20, 31 March 2021

Version 2.5.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.

Update file

Copy the v2.5.1 update tarball file to the big SD card, power on the camera, and wait around 7 minutes for the camera to finish updating.

Version details

Build host: linux-vm
Built by: tfischer
Build date: 20210324201657
Build tag: ssc1
Build hash: 516ebe87
Build version: v2.5.1rc14

Release Notes

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 or first in first out) or save the most recent capture first (LIFO or last in first out).
  • 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 file saved - Allows captured video files to more easily integrate into video analysis software systems.
  • 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.
  • Camera naming 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.
  • To fix the defect where USB is occasionally not recognized when the camera is powered on, checking for USB devices is delayed until after the camera is running. This means the camera will lock onto SD card for video storage before USB storage is detected. Previously USB had priority if both were available at power on.

Improvements between v2.5.1rc13 and v2.5.1g4:

  • Fixed defect that kept user added URLs from being loaded properly.
  • Added /reboot and factory_reset, in a manner that they return a CAMAPI_STATUS code before the camera reboots. Add logic to hcamapi so you can optionally wait for the reboot to finish before hcamapi reboot() or factory_reset() returns.
  • Added camconstant CAMAPI_STATUS_TIMEOUT=7, which is only used by hcamapi.
  • NTP drift files now stored in non-volatile /mnt/rw file system for better time accuracy.
  • Added /reboot2 and /factory_reset2 which are low level versions of /reboot and /factory_reset. They do not return a response, but may work if the camera is misbehaving to the point of not processing /reboot and /factory_reset properly. Intended as a backup for cases where the camera can not be physically reached.
  • Added /trigger_hw, which has less jitter than /trigger, but at the expense that the return code doesn't indicate if a trigger actually occurred. Intended for use by user added URLs software running in the camera.
  • Install HTML version of camconstants and hcampi documentation at http://10.11.12.13/static/sdk/camera
  • Fixed webUI progress bar position after a capture is complete.
  • Fixed webUI bubble help issue that kept encode quality low from being selectable.

Resolved defects

201607011045 Power on camera with USB storage may cause camera to not properly detect available storage

Status: fixed

If you have a USB flash thumb drive or USB hard disk connected directly to the camera and turn the camera on, depending on the USB device, the available storage will not be detected.

SDK API changes

  • Added CAMAPI reconfigure_run(), which allow you to adjust settings that do not require a calibration. The key setting is ISO; you can increase or decrease the ISO over a limited range. The feature was added so you do not have to wait for all background saves to complete before being able to make a quick adjustment if a cloud goes over you stadium and the image becomes too dark.
  • Added CAMAPI rename_last_video() against my better judgement. The best approach is to pass the desired filename before capturing a video. However, some customers have a use case where they don't know the desired filename until after the trigger event. Use with caution as getting out of sync with the trigger event stream means you are renaming the wrong videos.
  • Added a series of new CAMAPI methods relating to adding content to the webUI.
    • webui_extension() - allows a filename (located in /tmp on the camera) which contains HTML/CSS/JavaScript to be added to the content provided to a web browser when the browser is loading the home page content from the camera. You can defined around 10 methods to override empty methods in the camera which allows custom webUI content to be added at all the interesting places.
    • led_override(), which allows you to blink any pretty colors you desire. Intended to be used to indicate a supported device (such as PocketRadar&#169) was connected via USB, but defined in a very general way.
    • accessory_state_update() - allows you to add, update, or remove an accessory from the list of installed accessories.
    • get_accessory_list() - returns a list of installed accessories, along with their current state.
    • write_file() and read_file() - you can save and retrieve content from the camera's file system. The intended use was to allow HTML contect to be downloaded to /tmp in support of the new rename_last_video(), but was defined in a general way. Most of the camera's file system is read-only, so you can only create files in /tmp, /mnt/rw, /mnt/usb, and /mnt/sdcard directories.

Developer changes

  • As part of [extending edgertronic camera functionality] you can now add content to the webUI, such as a status box, a new tab in the settings modal, and a list of user settings. A lot of documentation needs to be written so you can use this cool feature. Send us an email if you find this feature intriguing and we will raise the priority so the documentation get created.
  • The camera no longer ships with runtime controlled debug output. The optional debug output was removed to improve performance.
  • You can replace the embedded web server (lighttpd) configuration file.

Known defects

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

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 Master camera's GUI since only the videos on the master will be saved.

Work around: you must press the save button on the master and all the slave 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 master and slave cameras. Unplugging genlock cable may trigger both master and slave 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

Older releases

All cameras can safely downgrade to version 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:

  • Network configuration via the web UI
  • 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
  • Underclocking (may improve image quality)
  • Add support for <video> tag in HTML served up by the camera (waiting for the Chrome browser to natively support H.264)
  • Add support for camera telling web U.I. when a status change occurs
  • User supplied gamma correction table.
  • Auto exposure where the camera helps you select the best ISO setting value.
  • 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.
  • 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)

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 master genlock camera.