Ninja V Firmware
Roman Bayramdurdiyev
AtomOS 11 is the first major redesign of our bespoke operating system since 2018. It was first revealed with the launch of the Atomos Ninja, Ninja Ultra, and subsequently the Shogun and Shogun Ultra that followed soon after.
Beyond the re-design and performance optimizations, AtomOS 11 also brought exciting new features to our latest Atomos Monitor-Recorders. Those features can now be unlocked on your Ninja V by purchasing a feature activation token via the MyAtomos portal.
Note: Upgrading your Ninja V from AtomOS 10 to 11.04.01 is irreversible. Due to various optimizations across the entire AtomOS firmware architecture, it should be noted that once updated to this latest firmware, it will not be possible to revert your Ninja V to any firmware version prior to AtomOS 10.94.00.
Moving forward, there will be no further updates to AtomOS 10, so updating to AtomOS 11 and above will be the only method to get updates for future ProRes RAW compatible cameras and general bug fixes.
The visually stunning AtomOS 11 operating system offers a fresh new look with countless optimizations to increase performance, usability, and some impressive new features. We can't wait for you to explore it.
Scheduled Play is also part of the PlaybackAssist feature set, allowing users to choose the time when the device should start playing back specific files. This could be after a user-defined timer has elapsed, or at a specific time of day.
Similarly to PlaybackAssist, the brand new RecordAssist feature allows you to schedule when you want your device to start recording. The recording can start at a specific time, or when your previously configured timer has elapsed. This also applies to the Timelapse function, making RecordAssist a perfect fit for situations where you have to configure your device before an event, or for the early morning hours when capturing a sunrise.
Note: The EL Zone System exposure tool can only be activated when our device detects either a Log or RAW Input. It's not selectable on the Ninja V when cameras are outputting video with Rec.709 or generic non-LOG picture profiles to it.
These clips are significantly higher quality than our 1080p and 720p proxies, and they're perfect for quick-turnaround jobs and every scenario where high quality C2C clips will end up in the final edit.
By pairing two AtomOS 11 devices to Atomos Cloud Studio, you can configure either of them as a wireless transmitter (TX) or receiver (RX). As long as you're connected to the Atomos Cloud via the internet via an Atomos Connect and if your Cloud subscription allows it, you can send a live video feed from one AtomOS 11 device to the other. No additional wireless equipment required.
I picked up my Atomos Ninja V yesterday and have been playing around with it a bit as I have never used a recorder before. I had an old SSD lying around which is a Samsung 84O and formatted it using the Ninja V. I recorded a few videos from the Nikon's Z7 without issues.
However, when it comes to connecting it to my laptop (Macbook Pro with Mojave) it displays a warning message first, "macOS can't repair the disk "AtomosV". I have ignored the message and can copy the files off the SSD with no problem.
Additionally, I can't seem to be able to copy files onto the SSD as it is in Read Only mode. I am surprised as to why the Ninja V would format the drive in such a way that the permissions becomes read only. Therefore I can't copy the firmware on to the SSD in order to update the Ninja V.
Due to the weird state the SSD gets into when being read on the MacOS which causes DiskUtil to fail upon erasing the SSD. I dont know what I did but I managed to reformat the SSD to exfat. Plugged it into the Ninja V and viola it works!!!
Even got the firmware updated but I noticed skippy the kangaroo appearing on the recorder on a few occasions. Just maybe I need a new SSD. For now it will suffice since I am just shooting random things at home and trying to get familiar with the whole new set up.
Without really tried to build it, two things you're doing different:
1. You need to run the script from C:\Prusa-Firmware-Buddy-master\python38\ directory
2. Provide some parameters based on what you want
I have the same problem. I didn't do much work with Python and i don't know how to run scripts and i would really appreciate some help with building the files for STM32CUBEIDE so i could look more into the firmware. The only problem for me is the part where you do this:
"Although it seems a bit pointless to document how to create signed builds if you are not a Prusa dev." I guess it's part of the open source ethos. Also, I assume that provided you remove the break out thing, you could create a signed build to a different signature?
The simple truth: The instruction on github is not complete. The Master-Branch actually a "developing" version, not always funtioning. You should not clone it (untill you are realy a develloper). You should clone a "Release" version instead.
But I get this error, I think I have everything that is needed for the compiling process installed.
I can edit marlin and compile it with Vsc or arduino, but I have no clue what I am doing with python.
I have tried to read the instructions on github and banged my head on to a wall for a week now, but to no help.
So I hope someone could point me on to the right direction, or give me the ready version of 4.1.0 with 415 e-steps.
Would you mind sharing exactly what path you changed it to? I am assuming this is my problem as well since jsmn, inih, TMCStepper, and Catch2 directories are all empty in my lib directory (release 4.2.1).
So, it has occurred to me I could load that same firmware .wav as a sample into my digitakt. Maybe if I add Digitakt reverb & delay to it as I route it to the Zen Delay I can create my own firmware upgrades?
Mine made this whining noise - this was with nothing attached to the unit just to make sure it was the Zen making the noise and not the synth attached if that makes sense (using the BP filter made it worse):
=1
I had one for 2 weeks. I found that there was a frequency that would resonate in the filter. I contacted them and they said that it was how the hardware worked. They said that once the delays were engaged it would mask the sound. However, I wanted to use the filter on its own at times and I found this to be annoying. I also became sensitive to that sound and started to hear it (or imagine it) in much of the stuff I did with it. I sent it back in the end.
Hello again, it seems that I am doing something wrong when adding a device to ESPHome in HomeAssistant because when loading the firmware the lamp stops working. I leave some screenshots of how I add it and of the .yaml code in case someone can help me:
The choices that you get when creating a new device in the dashboard are not important. The YAML file holds all configuration options for the device firmware. This means that the platform and board are also configured within the YAML file. So you could even start with an ESP8266 board initially, but when using my example.yaml the correct board is still used for the build.
The only possible flaws I see is that something got wrong in the example.yaml file or something I did wrong when installing HomeAssistant and ESPHome. Now I have hard weeks of university but as soon as I can I will get back on it and load H.A as an OS on an OdroidnC2 and start the process from 0.
Note that ESPHome flasher will flash things like the boot loader code and partitioning layout as well, required for starting up the device. If you only flashed the firmware.bin file onto the ESP32, then things might be missing, causing a boot failure.
I use the lamp as a wake up lamp for mornings, it really work great. But I have a little problem, I want to power on the lamp with a fixed color, it always power on with the last color I use. Is it possible to power on the lamp with red color always?
The pad that broke is TX. That corresponds to the pin that you soldered to now. So that looks okay to me. Maybe try reversing RX/TX on the nano? I never used that setup to flash, but if you get no results at all, then reversing them might be a plan.
What kind of environment are you using? If I use the official Docker v2022.2.3 container, the version numbers of tool-cmake and tool-ninja are different form the version numbers in your logging. See part of my logging:
Heather recently alerted me to the recent release of a firmware update, Atomos 4.0, for the Ninja 2. This new update gives the user the ability to record to Avid DNxHD in addition to ProRes. Thus is a major update for those who aspire to the highest quality possible will appreciate.
c80f0f1006