Tracking comet C/2022 E3 ZTF

On 5 Feb 2023 I tested the tracker on the "green comet" aka C/2022 E3 ZTF. 

5 x 60 sec exposures, "fog-reduced" using GIMP levels adjust tool. Because the comet itself is largely fog, this does have the downside of diminishing the comet a bit. Swings and roundabouts I guess.

I'd not realized just how much the comet would move in the 22 minutes I was capturing the images, so I though it illustrative to combine them into a animated gif. I had to align the star field manually, so it jumps slightly between frames, but overall I was reasonably pleased with the result.

My notes from the night:

Green comet C/2022 E3 (ZTF) travelling through the constellation of Auriga for 22 minutes on 5 Feb 2023 between 22:07 and 22:30. A sequence of 10 x 60sec images. Camera Canon 5D3 with 200mm lens on home-made astro-tracker.

Bright star in the upper left is Capella, 1 deg 38 min distant. Vertically above the comet and 0 deg 14 min distant is HIP 24109, a mag 5.65 star. The comet is travelling through a triangle of mag 11 stars and moved approx. 7 arc mins during the 22 minute sequence.

The moving "blur" to the upper right of Capella is either a UFO or dirt on the camera lens/mirror. Subsequently checked the lens/mirror and no marks detected. (... cue Twilight Zone music!)

Tracker testing (2)

It's almost a year to the day since I posted the last update on testing. That's not because I've not being making progress, I've just not got around to writing about it. My bad.

The "horseshoe" star shapes I was getting suggested to me that the rod gimbals needed improving. These were the supporting pieces that held the threaded rod and allow it to remain perpendicular to the axis of the tracker itself. They were crudely pivoted on the points of screws that projected through from the sides of the block that held it to the main tracker arms. It's possible that if the axis of the pivots was not truly parallel to the tracker boards and perpendicular to the tracker axis then the turning of the rod could introduce some overall oscillation to the mechanism.

Eventually I decided to replace the pivots with hinges, that would create a more precise mechanism and hopefully fix the problem. Because the supporting pieces for the rod had been made separately and just screwed on to the tracker boards, it meant I could replace them with new ones made to accommodate the new setup. The images show how this was done. The centre of the rod aligns with the axis of the hinges, thus maintaining the correct geometry. The whole thing now moves much more precisely.

It's gratifying that now I've made these improvements to the construction, the tracker tracks properly with little or no correction needed to the geometric calculations built into the software i.e. I don't need to tweak the speedfactor through the DIP switches.

Here's a 60 sec tracked exposure of the Pleiades, as captured and after adjusting the input levels with the Gimp to remove the background fogging as much as possible.

I'm pleased with this, and I'm not sure that such a simply constructed tracker could deliver any better results.

As I mentioned previously, my suburban sky is horrible with light pollution, anything much longer than a 60 sec exposure is so fogged as to be a waste of time. However, my brother lives in one of the darkest skies spots in the country, so my next plan is to invite myself for an overnight stay. Roll on the clear weather!

Tracker testing (1)

My equipment is a Canon 5D3 with a 70-200mm L USM F4 lens at 200mm, ISO 800.

I started with 30 sec exposure.  Until these were looking good there wasn't any point in trying any longer exposures.

Initial results were disappointing, and inconsistent which made it difficult to understand exactly what was going wrong. There was a mixture of issues:

1. star images streaked inconsistently in the tracking direction
2. star image movement in other directions, sometimes in a sort of horseshoe shape
3. the whole star field drifting in the tracking direction from image to image

(3) is fairly clearly that the tracking speed is too slow (or fast, depending on the direction of drift).

(1) would also appear to be a tracking speed issue, although the inconsistency of the streaking made it difficult to understand quite what was going on.

(2) would seem to show movement in some other direction: the "horseshoe" shape wasn't always exactly that shape, and often with different orientation. Nevertheless it suggested some sort of oscillating movement, not random like a shaky tripod.

30 sec exposure of the Pleiades showing "horseshoe" errors

I concluded that there were two main issues:

The first that there was something wrong with the stepper motor, which could account for problems (1) & (3). I was already suspicious that it was not turning consistently. I also had tried tweaking the speedfactor setting on the Photon to fix issue (3), and had varied it by up to 20% before the star field stopped drifting (and even then it wasn't completely consistent). I had difficulty believing that my calculations for the code could be this much wrong. I decided there was something broken or slipping in the internal gear train so I replaced it (£10 for a pack of 5 on eBay!). It turned out that there are a number of variants of this ubiquitous 28BYJ-48 motor, and my original was one of the unusual ones, with a different gear ratio. This went some way to explaining some of the problems I'd had.

Secondly I decided that issue (2) was down to the play in the gimbal axes. I'd assumed that the quality hinges would prevent any lateral movement of the plates, but this appeared to be what I was seeing, driven by some oscillation in the gimbals. I'd crudely made them of a steel rod (actually a sawn-off nail!), so I replaced these with screws that fitted into the gimbal blocks tightly but still allowed free movement.

These two changes improved things significantly, with most of the issues disappearing.

30 sec exp. Pleiades: no tracking and tracked

 

120 sec Orion Nebula

Stars still don't render as perfect points, so more investigation needed. The 120 sec image of the Orion Nebula is encouraging. Testing is painfully slow because of the scarcity of clear nights.

Notes on Imaging Sessions

I estimate my night sky in Leamington Spa is a Bortle  class 7.

I record images directly onto my Linux computer via a 5m USB cable, using gphoto2 to control the camera. It means that, once I'm set up, I can stay inside in the warm :)

Barn door astrotracker project

I built myself a barn door tracker.

This is an astrophotography device to cancel the movement of stars caused by the Earth's rotation. Without something like this, photographs of the stars will rapidly show trails. There are many forms of equatorial drive to counter this movement, mostly costly, and a barn door tracker (aka a Scotch mount) is something that can be built cheaply as a DIY project (and I like those). Search the internet for more general info about them.

My tracker is based on the common design of two hinged boards (plywood in my case) driven apart by a straight threaded rod. The rod is an M6 size, which has a thread size (pitch) of 1mm, and is driven by a motor fixed to the lower board, and rotates in and pushes against a M6 nut fixed to the upper board. I was intending to fix the boards using a piano hinge, but it had too much play in it to be useful. Instead I used two high quality brass hinges, which are tight and have no play at all.

The simple rod type barn door tracker inherently suffers from the fact that the relationship between the length of the rod and the change in angle between the boards (i.e. the tracking angle) is not linear, but varies as the sine of the angle. This means the increase in the angle for a same amount of rod gradually decreases as the rod lengthens. The discrepancy is not significant for small angles but increases as the angle increases. Rods driven by a constant speed motor will therefore suffer this problem; there are more complex designs involving multiple boards that can reduce the error, but all this goes away if the motor speed can gradually increase to compensate.

At the time I chose to use a microprocessor and stepper motor, I don't think I really appreciated all this. Building something that needed a precisely geared arrangement from a fixed speed motor without any obvious means of finely adjusting it looked too hard, whereas I had a spare microprocessor lying around and have a background in IT. And importantly, this way looked way more fun!

So, this is what I did...

The rod is driven by a stepper motor controlled by a microprocessor. The motor (underneath the blue shaft collar) and upper nut are gimballed, allowing the rod to remain perpendicular to the axis of the hinge. This somewhat simplifies the calculation of the tracking angle.

The Particle Photon microprocessor drives the 28BYJ-48 stepper motor via a ULN2003 driver (the latter two £6 together on eBay). The motor is a real budget job but is the only stepper I've found that uses 5V and can be easily driven by a processor such as the Photon (and more commonly an Arduino).

Polar alignment

For polar alignment I use a green laser that was originally fixed to the top board, but I felt it was more accurate to fix it tightly against the hinge(s). One problem I discovered with green lasers is that they stop working in the cold (below around 5C). To overcome this, I bought a USB powered cloth heater to wrap around the laser.

Software control

The microprocessor cycles continuously through the code. In each cycle it calculates the angle between the boards required to match the sidereal turning rate and converts it into the amount the rod needs to turn. Using simple trigonometry this is translated into the length of the rod, the number of turns of the rod required to achieve it, and hence the number of motor steps. If the calculated number of steps has not yet been made, the motor makes one step forward. The tracker needs the rod to turn at roughly 1 rpm;  the processor cycles at a vastly higher rate than is needed to avoid missing a step.

Software control has at least two major benefits:

• The motor speed can be varied and determined by the tracking angle required; that is, the tracking angle determines the motor speed, and not the other way around as in a purely mechanical design. This means there should be no inherent error in the tracking speed.
  
• It's easy to fine tune the tracker's motion by tweaking the programming.
  

Other designs I've seen have the boards initially parallel so the starting angle of the tracker is zero. With mine, the angle does not start at zero because of the way I constructed it (I wanted space between the boards to install the electronics). The initial angle - formed by the hinge pivot and the gimballed fixings of the rod - needs to be added to the angle delta before the corresponding rod length is calculated, and then the initial length of the rod subtracted from the result. The code looks like this:

elapsedMillis = millis() - startMillis;
delta = 2 * PI * speedFactor * (elapsedMillis/millisPerSideralDay);
d = 2 * r * sin (delta+theta_init/2); // length in mm the bar should now be
turns = d - d_init;                   // number of turns (1mm per turn)
stepsNeeded = turns * stepsPerTurn; // number of steps to achieve this
while (stepsTaken lt stepsNeeded) { // are we there yet?
  setOutput(step);
  stepsTaken++;
}

The inaccuracy from not doing this correction is actually quite small, and very small for small angles, but nevertheless easy to fix in the code.

The variable speedfactor is a fudge factor, initially set to 1 but can be modified to fine tune the speed to match actual observation. A bank of DIP switches is wired into the processor, the settings of some of which can be read by the code and applied to speedfactor. The remaining DIP switches are used to control other aspects of the code, such as whether the Photon's wireless connection is enabled - needs to be disabled if a connection cannot be made.

 

Testing

Initial testing was disappointing, but more of that later.

Brown roll rims - why me?

Brown roll rim mushrooms are moderately poisonous and look disgusting. And for some reason, they grow in profusion on my side lawn. For someone who likes foraging for edible mushrooms, this is a great disappointment.

These guys obviously like my lawn. Perhaps it's because I've a large birch and beech tree growing nearby. The mushroom bible (Roger Phillips) says they grow to 12 cm. On my lawn they can grow to at least twice that size - this one was 29 cm across (the lens cap is 8 cm).

If I cut the grass at this time of the year I have to remove these mushrooms before I mow or - as I've discovered the hard way - they make a real mess.

I cleared them yesterday, the second time in four weeks, and filled two buckets...

... the mushrooms weighed 9.5 kg.

 Why couldn't they be ceps, or chanterelles?

Bovedy meteorite

In a previous post I mentioned my search for information about a meteorite I actually saw fall while at Reading University. It's surprising that I found it so hard as it turns out to be quite notable. It's even mentioned in one of my astronomy books that I've had for years!

It's known as the Bovedy meteorite, after the place in Northern Ireland where the largest fragment was recovered, and fell on 25th April 1969 at around 21:25. A second fragment fell through a roof in Sprucefield. I'm obviously interested because I saw the meteor, and wanted to remind myself about it. (Note: a meteor is what you see in the sky, it's a meteorite when it hits the ground.)

I looked up the Times archive for the following day (now I know where to look!) and found a pretty lightweight item titled "The night a star fell on Ireland" that was a report from the Ballymurphy and Ballynahinch area of Co. Down. The internet however has far more useful data.

The most confusing thing for me is the track of the meteorite, because it doesn't agree with what I remember.

An article in Nature (3) includes a map showing the estimated track based on an extrapolation from the location of the retrieved fragments. This shows the meteorite crossing the English south coast at around Bournemouth and travelling in a NW by N direction. That this track is based on two hard facts about the meteorite, namely the location of where pieces fell, makes it pretty convincing. However, I'm unhappy with it because it conflicts with my memory of the incident. Memories can certainly be untrustworthy after 45 years, as shown by the fact that I remembered it happening in the summer (that was because it was in the evening and still light, or at least not dark, so I think I can be forgiven), but I do clearly remember where I was and what I was doing.

I was in St Patrick's Hall of residence at Reading University, playing bridge, and sitting facing the window. My room was in "K" block, where the windows face directly north-west, and my clear memory is seeing the object in the sky tracking to the left, and we watched it until it disappeared over the horizon. From this observation, the meteorite must have passed to the east of Reading, whereas the Nature track puts it 50 miles to the west, and so it would have appeared to track from left to right. I'm not sure I would have even seen it if this was the case.

Red track from Nature, blue track corresponds more with my observation

In the map, the numbered points are:
1 - Bovedy
2 - Sprucefield
3 - Shrewsbury
4 - Salisbury area
5 - Reading
6 - Preston
7 - Doncaster
8 - London
9 - Sussex area

So could the Nature track be inaccurate? It does look pretty convincing, but I can't shake the fact that it's not consistent with what I remember. The big problem with a track that is consistent with my memory is of course that it doesn't pass through the two fragment sites. This isn't necessarily impossible - fragments fall a long way and can be surprising affected by wind, although I have no knowledge of the wind conditions on that night.

Looking at other information, the The Meteoritical Society record (1) says "The fireball was seen all the way from Sussex through London, Doncaster and Yorkshire to Northern Ireland toward Belfast." - all the points in England well to the east of the Nature track. Another report (7) mentions an observer in Preston, Lancs, and another who saw it "over Shrewsbury". Also, it says "It was moving from ESE to WNW very rapidly." (like my track). The Nature track puts it travelling NW by W, a less oblique angle. These all suggest a more easterly track.

To be fair, the observations apart from mine aren't necessarily a problem: given the height and brightness of the meteor it would have been visible from a long way away. Also the greatest population of the UK lies to the east of the country, so sheer numbers would suggest that is where most observations would be made.

Perhaps I just have to accept that my memory is wrong. It may not have been as impressive as the Chelyablinsk monster but it was impressive nevertheless, and probably the biggest I will ever see.


There's also the question of how big the original object was, and how much of it was recovered. In The Data Book of Astronomy, Patrick Moore said "The Bovedy meteorite was well observed during its descent, but the main mass was not recovered, and almost certainly fell into the sea". Everything I've read only mentions the pieces found as "fragments" - I don't think anyone suggested that the object found at Bovedy was the main body of the meteorite. I vaguely remember from the time that some wild figures were kicked about (100 tones? 1000 tons?). More reasonably, the rounded shape of the Bovedy fragment suggests to me that is was part of a roughly football sized object, which would be around 20 kg given the normal density of stony chondrites.

In general - and it's so dependent on factors like size, speed and angle of descent - meteorites become visible at a height of around 100 km, and, assuming they've not burned up entirely, have slowed enough to stop ablating and become invisible at around 20 km and at a speed of 2-4 km/s, thereafter taking up to 3-4 minutes in free-fall to reach the ground (8,9).

Using these assumptions, it's possible to estimate roughly how far the main body of the meteorite may have travelled. It was still visible at Bovedy as it reportedly passed overhead (2), so if we assume it was 100 km high when first seen over southern England, and 20 km high at Bovedy, a distance covered of approx. 500 km, then this gives an angle of descent of about 10 deg.

Using all this, projectile dynamics (and taking into account air resistance) gives the following distances to the ground and time taken for a 20 kg spherical object, for various initial dark flight speeds:

Speed(m/s) Distance(km) Time(secs)
 2000         31         101
 3000         35         100
 4000         39          98

This would support Patrick Moore's assertion that it ended up in the sea.

In truth, I accept that it's probably nonsense to attempt calculations like these. Too many assumptions based on inaccurate data and guesswork. But I enjoyed doing the calculations!

References

1. The Meteoritical Society Bulletin Database record (http://www.lpi.usra.edu/meteor/metbull.php?code=5121)

2. The UK and Ireland Meteorite page (http://www.meteoritehistory.info/UKIRELAND/NEIRE.HTM)

3. Recent Fall of the Bovedy Meteorite, Northern Ireland, Nature, vol 23, July 25 1969 (images)

4. The Data Book of Astronomy, Patrick Moore, p248

5. 40 years since the sky fell on Ulster (http://www.newsletter.co.uk/news/regional/40-years-since-the-sky-fell-on-ulster-1-1884295)

6. The night a star fell on Ireland, (London) Times newspaper article, April 26 1969

7. Turning UFOs into IFOs; Part 1: Fireball Meteors (https://planetpreternatural.wordpress.com/tag/bovedy/)

8. Fireballs and Meteorite Falls, International Meteor Society (http://www.imo.net/fireball/meteorites)

9. American Meteor Society, (http://www.amsmeteors.org/fireballs/faqf/):
"At some point, usually between 15 to 20 km (9-12 miles or 48,000-63,000 feet) altitude, the meteoroid remnants will decelerate to the point that the ablation process stops, and visible light is no longer generated. This occurs at a speed of about 2-4 km/sec (4500-9000 mph)."

 

Update Feb 2024

I heard from Paul Littler who recently contacted me after reading this. He also saw the meteor that night from where he lived not far from Merseyside, and as with me it made a lasting impression on him. Paul had done more research than I'd done, and had contacted the Armagh Observatory where most of the recovered pieces are now kept. They told him that the meteor would have been the size of an American Fridge when it entered the atmosphere. A quick calculation using the average meteorite density of 3 gm/cc yields a size of around 3 metric tons!

This seems enormous, and you'd think one of the largest seen to fall on the UK. But meteors are recorded by the size of recovered meteorite fragments, without much or any speculation of initial size, and in terms of recovered weight (3 fragments with a total weight of around 8 kg), the Bovedy meteor ranks only 11th on the UK list. Nevertheless, since some or most of it probably landed in the sea, it may well still be one of the largest observed falls.

 

PCSecrets

PCSecrets is a PC application that holds information that you want to keep secret - protected by a master password and strong encryption.

The program is designed to be a PC counterpart of the Secrets for Android app. It uses the same data structure and provides a synchronization mechanism that allows easy transfer of secrets between the two. For those who find the PC environment  more comfortable for data entry and editing (i.e. keyboard/mouse/screen), PCSecrets provides an alternative environment for managing your secrets. Synchronization is also effectively a form of backup.

Encryption

PCSecrets uses AES-256 bit encryption which is the strongest commercially available encryption scheme. In addition it employs bcrypt, which implements key stretching with an adaptive key setup phase.

The purpose of the bcrypt algorithm is to introduce artificial but complex processing that takes a calculated amount of time into the key hashing processes. This introduces a finite delay into the setup of the encryption and decryption ciphers that will be used. In PCSecrets, this setup phase is configured to take 1 second (as measured on the current computer) which is not really perceptible. However, the consequence of this delay is that any attempts to break the encryption by guessing the password are considerably slowed down, since each password guess is forced to go through the same processing to create a decryption key.

This makes it highly resistant to dictionary attack.

(See "key stretching" and "bcrypt" on Wikipedia for more information.)

Features

Features of PCSecrets are:

• the same strong encryption used by Secrets for Android
  
• a form of cryptographic plausible deniability, whereby a hidden second set of secrets can exist that is protected by a different password
• synchronization with multiple Secrets for Android devices i.e. phones, tablets
• synchronization data is always fully encrypted
• automatic backup on save
• import and export of CSV data
• written in Java, so can be executed on any system with a suitable Java Virtual Machine

An individual secret is a collection of text fields. These have names such as userid and password, and lend themselves to data used to access Internet sites, but this is only a suggestion and the fields can be used in any way you want. In particular, the note field is provided as a catch-all for holding any unstructured text. The exception is the first field, the description. This is used as the name of the secret, and must be unique.

Installation

Download the executable jar file from (email me for the moment) and place on the desktop or some other suitable location. There is no install process as such - just execute the program by using the Java executable already installed on your computer.

If the default open action for a .jar file on your computer is to open using the Java executable, then simply double-click on the jar file. Otherwise right-click on the .jar file and select the Java executable to open with.

If Java is not installed then you will have to do this first. You can use for example the  Sun Java or OpenJDK.

Getting Started

When first run the program will prompt for an initial password. Try not to use a simple password - a mixture of letters, numbers and special characters but no spaces (leading, trailing or embedded) - and don't forget it! Subsequent executions of the program will require the same password to be provided - if you can't then your secrets will not be accessible. The password can be reset by providing a new one, but all existing secrets will be lost. There is no way to recover a forgotten password.

Optional second set of secrets

You can initially provide two passwords i.e. separated by a space. In this case you actually create two sets of secrets, independently encrypted and independently accessible. When you subsequently start PCSecrets, you can provide either password to access the corresponding set of secrets.

The two sets of secrets are stored as a single chunk of binary data. Externally it is not detectable that two sets of secrets exist, so if someone were to force you to reveal the password(s) to your secrets, you could deny that a second set of secrets existed without anyone being able to prove otherwise. This is known as plausible deniability,

The Main Window

The main window shows a list of secrets on the left, and a form showing the details of the selected secret on the right. Beneath these is a row of buttons. The buttons below the list apply to your secrets as a whole; those below the form apply to the current secret or data in the form.

Creating a secret

To create a new secret, simply type your data into the form and click "Create". The description of the secret becomes its name, that is shown in the list on the left. (The term "description" is used to make it compatible with Secrets for Android - in data terms it is the key of the record.) The set of fields that make up a secret are the same as used by Secrets for Android, and all values are optional apart from "description".

Create will be ignored if a secret with the same description already exists.

The "Clear" button is provided as a quick way to clear the form values before creating a new secret.

Updating a secret

Select the secret by clicking on its entry in the list. Make your changes and click "Update". If you change the description, you are now dealing with a different secret (because you've changed the key). If it doesn't exist, update will be ignored. You can copy a secret by selecting it, giving it a new description and clicking "Create".

If you modify a secret but forget to click "Update", the changes will not be saved.

Deleting a secret

Select the secret (or type its name in the description field) and click "Delete". If you attempt to delete a secret that does not exist, the request is ignored.

Saving

Click "Save all" to save changes to disk. If changes have been made and you exit the program without saving, you will be prompted to do so. If you do exit the program without saving, changes made since the last save will be lost.

Import and export

Secrets can be imported and exported in CSV format. This is a simple and commonly used data exchange format.

Import

Select File->Import.

Use the selection dialog to locate the .csv file to be imported and click "Open". The subsequent Import dialog provides for control over how fields in the imported file are mapped to Secrets fields.

The Columns section  shows how many fields there are in the imported file (by analysis). It also shows the contents of the first record, to determine if a header record is present. If a header exists, and it provides field names that match the Secrets field names (Description, Id, PIN, Email, Notes) then a mapping between these matching fields will automatically be created. A Timestamp field can also be provided to give a record a last updated time.

If no header exists, the fields are identified by position, #1, #2, etc. The mapping of fields is sequential.

To change any mapping, click the Input field name in the Mapping section and select, from the dropdown, the correct field.

When the mapping is correct, click "Import".

Export

Select File->Export.

Choose a location for the exported file, provide a file name and click "Export".

Synchronizing with Secrets for Android

(This feature is currently undergoing testing and is not yet available with the current version of Secrets for Android. It will also require an additional app, the PCSecrets sync agent, to be installed on the Android device alongside Secrets for Android)

To synchronize your secrets, click the PCSecrets "Sync" button and the program will wait for a mobile device to connect.

Secrets are sent to and from the device only in encrypted format, and the same password for encryption and decryption must be used at each end. This does not have to be the same as the one used in either PCSecrets or Secrets for Android. By default PCSecrets will expect the device to use the PCSecrets password. Alternatively, a preference can be set so that a different password can be provided when "Sync" is clicked. Either way, the password to be used has to be configured in Secrets for Android so that both ends of the exchange use the same password.

The program will automatically try to make the secrets in each location the same. In doing this, it follows these rules. A secret that:

• exists only in one location is created in the other
• has been updated in one location is copied to the other *
• has been deleted in one location is deleted from the other *

* provided that the secret in the other location has not itself been modified since the last sync operation. If it has been, a conflict exists which the program cannot resolve automatically, and you will have to indicate what you want it to do. The program will open the sync window so you can do this.

Normally the sync window will only be shown if a conflict exists that you have to resolve. If there are no conflicts the sync operation will complete automatically. Alternatively, you can set a preference so that the sync window is always shown even though they are no conflicts. You may want to do this so you can see exactly what is going on.

The Sync Window

The sync window shows the list of all secrets on the left, and two panels on the right which show the contents of the selected secret on the PC and on the mobile device. Items in the list are colour coded to show their status, and checkboxes can be used to show or hide the different categories.

By default only secrets that differ between platforms are shown, although all secrets can be shown by checking the "Show unchanged" checkbox.

Everything except conflicts are shown for information only and require no action - if secrets differ, the program determines where the latest version is and automatically uses it to update the other location. Note that the content panels are normally read-only; only in the case of a conflict will you have the opportunity to modify the contents of a secret.

Conflicts are always shown and must be resolved before the sync operation can be completed. If you cancel the sync operation no changes are made.

Resolving conflicts

A conflict occurs if a secret has been modified on both the PC and device, or been changed on one and deleted from the other, since the last sync operation. In both cases, the user has to indicate how to proceed, as follows.

If modified in both locations

Select the conflicting secret in the list window. The contents of the secret on PC and device are shown in the corresponding forms. You should update the PC secret to reflect the correct secret contents, and click "Mark as merged". If the PC secret is already the correct version, just click "Mark as merged". If the device secret is already correct, then click "Copy to PC Secret" and then "Mark as merged".

When the sync completes, the PC secret will replace the device secret.

If modified in one location and deleted from the other

Select the conflicting secret in the list window. The PC and device panels will show in which location the secret has been deleted. Your choices are:

• If the deletion is correct i.e. you want the secret also to be deleted from the location where it remains, click "Confirm deletion"
• If the deletion is not correct i.e. you want the secret to be reinstated in the location from where it was deleted, click "Undelete". When the sync completes, the secret will be reinstated from the existing copy.

Sync timeout

By default the mobile device will only wait for two minutes for the sync operation to complete. This is so communication won't hang forever if sync was selected and PCSecrets is not active, or if there is some communication problem. You can change this value in the agent configuration in Secrets for Android.

If the operation does timeout before it completes, no changes are made. The operation can simply be retried.

Sync with two sets of secrets

Secrets for Android does not support the idea of having more than one set of secrets. Sync simply operates with the set of secrets that is currently being accessed.

 

Preferences

Access via the File->Preferences... menu option. The Preferences window is divided into these sections:

Secrets
Allows you to specify the location of the PCSecrets directory.

Sync
Here you can change the port numbers used by the program. This would only normally be necessary if the ports are in use. Note that this requires a change to the Secrets for Android sync agent configuration so the same port is used.

Log Level
You can set the log level for diagnostic purposes. The log is created in the home directory and named java{n}.log.

By default the log level is set to warning. Be aware that with the log level set to a finer level (info or fine) diagnostic information may be written to the log that could be used to compromise the security of your secrets. So do not as a matter of course set the log level below warning, and if you do set a lower level for diagnostic purposes, make sure you reset the log level afterwards and securely delete the Java logs.


Backup
Backups can be automatically created whenever a save is performed. The number of backup files that are kept can be specified - when the number is reached, the oldest file is deleted when a new one is created.