Uc-ck Reset
Carlee Members
Reset then restore backup. A few of the recent firmware updates did the same thing to half of mine. A few times I had to go through a few backups on the SD card before I found one that worked. The most recent firmware worked fine for all the cloud keys I support.
So I reset the CK to factory defaults by holding down the the pin bottom on the bottom of the CK for 5 seconds. It then allowed me to login using the default ubnt ubnt password, forced me to change the password and then gave me access to the settings to restore the backup config file.
The firmware updates on the original cloud key determine the Unifi controller version. They are paired together. So factory resetting would load whatever Unifi controller version came with that firmware.
Firmware updates also update \ downgrade the Unifi version to the included version when applied. this is why I would always make a backup then do a firmware upgrade, then do the unifi upgrades on the Gen 1 cloud key.
I recently did a full reset of my laptop by reinstalling windows 10 from a bootable USB. I wasn't thinking through it apparently, because It removed the BIOS and everything that came standard on an OMEN laptop. I have since reinstalled what I think is the correct BIOS, but my laptop just takes forever to load certain things. And in the "About your PC" section, under device specifications, it no longer says anything about being an OMEN laptop. My warranty expired last year so I'm not looking for replacement parts. I'm assuming its software? I'm 18 and struggling through my first college classes because it is acting slow. Please help.
Is this going to reset my laptop with the correct bios and everything that came with the original OMEN? I already factory reset it, but it turned it into a basic pc without any of the OMEN features. Is the HP thing going to do the same?
The first thing I would recommend doing is booting the cloud key into recovery mode, to do that:
1. Power off the unit
2. Remove power
3. Hold down the little reset button (use a pin or something)
4. Apply power and keep holding the reset button for 10 seconds or until the little screen on the front shows you that its in recovery mode. Once its in recovery mode it will show you the IP of the interface. Browse to it.
13. The first thing we need to do is update the CURRENT installation. As of the time of this writting, the cloud keys had Debian 9 on them, were going to upgrade it to 10 but we need to get our base updated first. To do this, run the following commands one at a time
So, I have converted this Cloud Key Gen2 Plus from the original Debian system over to Ubuntu 20.04. It took a little work, and a few tries at the trouble shooting. I placed the following into a script, and used it to upgrade the UCK from Debian, back around to Ubuntu.
I know when you look at the script, the way the last upgrade went, your going to think, why do it this way. I will tell you a flat apt upgrade will leave you resetting the system back and starting again. However, *IF* you check apt upgrade, and upgrade ALL crypto packages first, you will have better success.
No they won't clock synchronously in the manner you describe. There will be a phase delay associated with the trace lengths being slightly different. Also how the microprocessor comes out of RESET will vary how the code operates.
You can't hook the same crystal to three processors. To have them use the same clock you can re-program the fuses to use an external oscillator and then provide a clock signal to the correct input pin.
"To have them use the same clock you can re-program the fuses to use an external oscillator and then provide a clock signal to the correct input pin."
Which I have been trying to do quite unsuccessfully!
I think running N-mcu's all with one external clock must work (provided all N-mcu's have got the same fuse settings). And all mcu's must do the same with a clock cycle precision (all events finish in a given clock cycle). The exception might be writing to internal EEPROM or using the watchdog timer (an RC oscillator) or mcu's with different die revisions. I cannot imagine the reason why they may not work synchronously. Mcu's are not the SDcards..
The another question is how to synchronise their operation (from the sw point of view)..
Using two crystals may lead to starting delays as each crystal starts differently (crystals are lazy, blocking capacitors differ in value) - so I would bet many thousands clock cycles difference is possible..
So I would suggest you to place a canned 16MHz oscillator on the board, connect to all mcus and try harder..
p.
The lower Uno has its low-fuse set to 0xBF, which sends the buffered clock signal to CLKO (pin 8 ).
The upper Uno has its low-fuse set to 0xE0, which configures it to receiving an external clock on XTAL1 (orange wire).
NB this does not work if you connect master-XTAL2 to slave-XTAL1 -- probably because the clock is programmed for a low-power crystal which generates a low-amplitude signal. If configured for a full-swing oscillator it may not be necessary to use CLKO (freeing up pin 8 ).
Apart from the low fuse both Unos are configured identically and run Optiboot v4.5. The two reset pins are wired together to ensure synchronised startup, although the start of the slave Uno is delayed for reasons I don't fully understand.
Technically, getting the uC to work with other clock besides a crystal/resonator is possible.
Getting the fuses set to do it is not easy. Installing the normal bootloader via the IDE with those fuse settings takes away those problems.
@tim7: nice experiment!
There is 4ms delay, right? The delay probably comes from the Start-up time xx CK/ 14 CK + yy ms, try setting with lowest xx and 0ms.
You cannot drive one Uno from clkout of the second one, as the 328p needs above number of clocks to start and there is a question when the Uno actually enables the clkoutput. The lowest I can see is 6 CK/14 CK +0ms from external oscillator.
Take a canned oscillator and feed both Unos with the output from that oscillator. It would be good to have the xtal capacitors removed. Set both Unos with SAME fuses - ie C0h low fuse (External osc 6CK/14CK+0ms)..
Reset - of course both Unos have to be reset at the same time - this might not be easy if there are capacitors connected to reset..
I think I'll stick with CrossRoads. My idea was to have one chip monitoring all of the sensors and sending the info to the second chip that would process the data and do logging and control functions. Of course there will be two different programs running on each chip, so the hex aint going to be the same. Sounds like I can do this much, but can't expect an accurate timing sync between them.
It turns out that the de-synchronisation is due to the error in the watchdog oscillator. One board consistently starts up 6% faster than the other, no matter how the main 16MHz clock is generated. Since optiboot uses the watchdog for its timing, even without a reset delay the sketches still get started at different times. The difference is 95ms for the pair of boards I tested.
It would still be possible to run synchronised software on two or more processors, but the bootloader would need to be modified (or eliminated), and some kind of external power-on reset circuitry would be needed.
One possibility is the hard reset: Disconnect the cloud key from the power supply, now hold down the reset button and connect it simultaneously with the power supply.
Important hold down the reset button until the LED on the top flashes white/blue.
Now you can access the Unify Manager interface by entering the IP address of the Cloud Key in your web browser. This is a fallback UI which allows to reset and update the firmware.
The question about Ubiquiti UniFi Cloud Key has already been answered, but there may be a better solution or alternative available by now. If you know it, answer the question now and increase your reputation as an industry expert in our B2B community.
Get help information regarding the applications. Still need help or access? Call 207-8888 to get assistance.EmailESSPasswordsRemote WorkTeleconferenceHorizon ViewPurposeProvide internet browser access for employees to their COSA email accounts.
Self-Service Password Management allows COSA employees to reset their own Windows passwords. If you get locked out of your Windows account for any reason or need to reset your password, Self-Service Password Management allows you to reset your Windows password.
Up for sale is a Ubiquiti networks UC-CK Unifi USB-C controller cloud key with 8GB SD. The cloud key was tested to power on and reset to factory defaults. The cloud key is in overall good physical condition with light signs of previous use. The Ubiquiti UC-CK Unifi controller cloud key comes with the 8GB SD card only.
1. This publication is effective upon receipt and shall be used with CSP 1500 (Mk. I Hagelin Cryptographer).2. This publication is a SECRET publication and shall be handled and accounted for direct to the Vice Chief of Naval Operations (Registered Publication Section) in accordance with U. S. Navy Regulations and the Registered Publication Manual (RPS-4).3. This publication will be distributed and used as so ordered by the Commander-in-Chief, UNITED STATES FLEET.4. The method of transporting this publication is as laid down in the Registered Publication Manual (RPS-4).5. When not in use this publication shall be habitually stowed in "Class B" stowage, and shall at all times be bound in a weighted cover by holders afloat.6. IT IS FORBIDDEN TO MAKE EXTRACTS FROM OR TO COPY THIS PUBLICATION WITHOUT SPECIFIC AUTHORITY FROM THE VICE CHIEF OF NAVAL OPERATIONS, EXCEPT AS PROVIDED FOR IN THE CURRENT EDITION OF THE REGISTERED PUBLICATION MANUAL (RPS-4).THIS PUBLICATION CONSISTS
OF NINE (9) PAGES
-2-
SECRETCSP 1502(B)INSTRUCTIONS1. This publication is to be used with the Hagelin Cryptographer, CSP 1500.2. The KEY consists of:(a) The Lug Positions on the Tooth Bars, changed three times monthly.
(b) The Pin Settings on the Key Wheels, changed daily.
(c) The Internal Indicator Enciphering/Deciphering Table.3. LUG POSITIONS: (See Table I)The chart showing the Lug Positions is arranged in a form having the same relative position as the assembly in the device. This assembly is located at the rear of the device and is exposed by unlocking and opening the top of the inner compartment. A tool is provided for rearranging the Lugs, and is clamped into place at the left side of the lid of the device. In rearranging the Lugs, care should be exercised that each Lug is firmly seated into its respective slot, otherwise the machine will not function properly. The numbers in the right hand column of the Lug Position Chart refer to the numbers appearing on the right hand wheel of the assembly, and the numbers appearing at the top of the columns refer to the numbers appearing on the bracket at the rear of the machine. An "X" appearing in a column under a number indicates a Lug is to occupy that position.4. PIN SETTINGS. (See Table II)Each letter on the Key Wheels has an associated Pin, which is located directly under the letter, and each Pin must occupy a position either to the right, or to the left, of the Key Wheel. In the chart of Pin Settings, the columns represent the Key Wheels, and each line shows the Pin Settings for a day of the month. A letter appearing on a line indicates the Pin associated with that letter (for the respective Key Wheel designated by the column) is to be to the RIGHT of the Key Wheel; a letter omitted indicates that Pin is to be to the LEFT of the Key Wheel.5. THE INTERNAL INDICATOR ENCIPHERING/DECIPHERING TABLE.Every message sent in this system must have the Internal Indicator (The Initial Code Wheel Lineup) enciphered in accordance with the Internal Indicator Enciphering/Deciphering Table. A special system of Indicators is used. Every message will have "XX" appearing as the first two letters of the first group, and "XX" appearing as the last two letters of the second group. (See diagram below) The remaining six letters form the Internal Indicator and are obtained by enciphering the Initial
-3-
SECRETINSTRUCTIONS - (continued)CSP 1502(B)INSTRUCTIONSKey Wheel Lineup in accordance with paragraph 7(c). The first two groups are repeated at the end of the message (in the same order). The following example illustrates a complete dispatch and is true in form only. It does not represent an actual encipherment.