globular

Very nice sketch. Can I ask a question? What does the P mean? Presumably S points to Mars's south pole and the south pole is defined by us earthlings as the one nearest the bottom as we look at it? (corrected for diagonals on a tilt and/or inverted images etc).

Thanks John - nice moist carrot cake please 😇

As we all know (from the link John supplied earlier in this thread) the formula for magnification for a common barlow design is M = 1 - X / Fl where M = magnification, X = distance of focal plane to barlow lens group, Fl = focal length of barlow lens group. Now I don't know what either X or Fl are for the Antares 1.6x, but because it claims 1.6x magnification this gives (by rearranging the formula) that X = -0.6 * Fl (Let's check that by plugging it back into the formula; M = 1 - -0.6*Fl / Fl = 1 - -0.6 = 1 + 0.6 = 1.6). If we make up that Fl = -100mm as a guess (the Big Barlow is apparently -90.8mm so it's probably somewhere around there) then we get X = 60mm. The Ethos 8mm focal plane is not at the shoulder so we need to adjust X and plug the new value into the formula to get the revised magnification. As we can see from this table, when used as a 1.25" eyepiece the shoulder of the Ethos will sit C (plus any adaptor height) above the top of the Antares and the field stop is F below the Ethos shoulder. Lets pretend we have a zero light path adaptor so we need to add C and subtract F (both converted to mm from inches) from X to give our new X' = 60 + (0.94-0.7)*25.4 = 66.1 And the 1.25" mode magnification M' = 1 - X'/Fl = 1 - 66.1 / -100 = 1.66x Now, when using it as 2" the Ethos shoulder sits on the top of the Antares and the field stop is F below. So X'' = 60 - 0.7*25.4 = 42.2 And the 2" mode magnification M'' = 1 - X''/Fl = 1 - 42.2 / -100 = 1.42x If we alter Fl (we just guessed it's value after all) then the results naturally change. At Fl=-50 M'=1.72 and M''=1.24 and at Fl=-150 M'=1.64 and M''=1.48. Maybe this means the Antares has a large focal length so that John's observation might be consistent with the science? Or maybe the design of the Antares means this simple formula does not apply? Or maybe the claimed 1.6x is a little out - it will likely be a rounded figure from the actual. If it's really a 1.69x (and the marketing guys rounded down the most they could reasonably get away with) then the 2" M'' recalculates at about 1.51x (at Fl=-100). I suspect it's a little bit of all three. I pretty sure, John, that your observations will have been be about right - but I think it's also likely that if you repeated them in 1.25" mode then slightly more magnification would have been apparent. But what's 0.1x or 0.2x higher magnification between friends? Surely the view in the eyepiece is more important than the numbers on a piece of paper?

Have to say I agree with James.

The two lines you are removing change the values in the array, not their positions. So I think you want to change 0,1,3,2,7,6,4,5,15,14,12,13,8,9,11,10 to 14,13,11,12,7,8,10,9,15,0,2,1,6,5,3,4 As you say, a clear head tomorrow will make it clearer.

The line dirn = 15 - codeArray[Gray]; returns a value between 0 and 15. The next line dirn = (dirn - 1) %16; applies mod 16 to a value in the range -1 to 14. Is the -1 really necessary? You want to shift the range over? Mod of negative numbers is notoriously dodgy with different languages implementing different solutions - some returning negative results which looks like what is happening here. I think your solution is one of the following: If you want to subtract 1 then add 15 instead, so the line becomes dirn = (dirn + 15) %16; If the -1 was a mistake then remove it, giving dirn = dirn %16; which is actually a pointless line because dirn is already in the range 0 to 15; is the line can actually be removed.

I notice you have replaced *1.5 with *3/2 (and other similar changes in other places). This is not the point I was trying to make. Multiplying an integer by a float results in a float and requires conversion before being stored in an integer variable. Best practise would be for the programmer to decide what type of conversion is required (round up, round nearest, round down, truncate, the list of options is endless). If none is supplied (as in your code) then some languages will error at compile, others will error at runtime, others will not error but will produce unexpected results (including memory leaks or unexpected values) and others will use a default conversion type (often truncate in the case of float to integer) and run just fine (if the default was the desired action). I suspect in this case the language will be converting it for you by truncating; and everything will run fine. But, as you were getting unexpected results involving an int variable without an explicit conversion, I thought it best to rule out any possible errors by suggesting you either supply an explicit conversion between variable types or change variable types to avoid conversions. Your change to *3/2 does not alter the fact that the result is a float (int divided by int is a float) so it still needs conversion to store the result in an int; also this change is slightly worse overall because it requires more computation. As you seem certain the PulseCount variable is the culprit (not the downstream int variables requiring float conversions) then all this is unlikely to make any difference to your issue; it really just becomes a question of programming style.

Do you know it's a rogue PulseCount rather than a rogue windGust or gustArray[] entry or speedGust value?

I'd still like to see some more consistency with your variable types. Mixtures of int, long and float together, without explicitly converting when cross assigning, seems a recipe for disaster; as does having int variables being divided and/or multiplied by 1.5 without explicitly saying how you want the remainders to be treated. Probably not the issue you're seeing - but until it's ruled out it just might be.

Vibration causing a one-off blip in the pulse that doubles the gust will not really show in the mean as you are averaging over a large number of pulses and only showing the average in round mph. One of your earlier tests had a larger gust blip and there was an increase in the mean then too. I suggest you re-run the test but rather than turning off the fan (with associated vibrations) put a piece of card in the way to divert the wind - very carefully so as not to knock anything. You'll then know if it's a physical vibration issue or some problem in the code when pulses stop.

Not been for a while (and was my pre astronomy days so I wasn't looking for sites) but it was all trees from what I remember. Where is a good spot there? Do you have coords?

I'd also suggest that you change meanArray and meanSpeed from int to long; there may be overflow breaches with int during the accumulations and this would cause the falling back to zero behaviour you are seeing. I know you are only (supposed to be) summing 200 readings before then calculating the average; so unlikely that it should be biting; but changing them to long, even if only temporarily, should allow you to definitively rule this in or out.

Hi Gina, The maths within do1mjobs relies on do3sjobs being called 20 times between runs; you have a /133 (and the 133 = 10 * 20/1.5). With connection issues causing 5 second waits between retries there may not always be 20 calls to do3sjobs and so your mean calculation will be too low (i.e dividing the sum of less than 20 speeds by 20 will lower the average speed). You could solve this by incrementing a counter in do3sjobs which is then used in do1mjobs instead of the fixed 133 (i.e. use /(10*counter/1.5); and then reset it to zero after it's been used in do1mjobs. I'm not sure why everything resets to zero though - it seems unlikely connection delays could last long enough to cause that.

Thank you very much for the advice Chris ( @BRADLEY 1953). I did view for about 30 minutes or so thinking WOW the whole time with a huge smile on my face - but my eyes are just not yet up to picking up enough detail to make a stab at a sketch; and I was too impatient to move on to other targets. I know I have a lot to learn and there is a huge difference between viewing and observing. I haven't yet purchased any coloured filters nor EPs beyond the stock ones that came with the scope - I'm trying to be patient and 'learn' what I need to improve my set-up rather than using newbie gut feel and end up making lots of expensive mistakes. But I just have to take advantage of the current Mars positioning so it looks like a new EP and a filter or two have made my shopping list.

Lovely sketch. Can you give me some advice? I’ve only had my scope a few weeks and still have everything to learn. I was looking at Mars around the same time as you but the image was far too bright for me to make out anything other than glimpses of darker areas on the surface. I have an 8” f/10 edge hd and 30, 15 and 9 mm EPs. The 9 gives about 225x and was my clearest view of Mars but just too bright. Is my aperture letting in too much light? Or do I just need to persevere and learn to train my eyes? Or maybe use more magnification with the associated brightness reduction? Or filters perhaps? Thanks in advance.

@John does the ES 2" 2x focal extender move the focus position? Sorry @Dantooine for hijacking your thread but I've been searching for this info for a while without success and with John mentioning it re the powermate I just had to ask him.

Yeah it's the top caps that are the problem. They should come with tethers to the EP body; a bit like camera lens caps. [(c)Globular 2020]

Can you post a link @Robindonne?

You can add a 2” nose extension which allows the addition of 2” filters without further adapters or faffing. Looking at John’s photo it looks like he has done this himself.

Here is my solution. Start with * Celestron 2" Diagonal #93519 * Baader 2" Inversion Ring #1508020 * Baader 2" ClickLock SCT #2956220 Remove the eyepiece barrel Add the inversion ring Add the clicklock Nasty screw grip barrel replaced with nice clicklock. And the light path is roughly the same (2mm shorter). Thanks again Louis for the inspiration.

Louis, your comment above prompted me to look closely at my Celestron #93519 diagonal and I discovered the barrel does indeed unscrew revealing a 2" SCT female thread on the eyepiece side of the diagonal. I've ordered a baader 2" SCT female to 2" SCT male inverter ring that will then allow connection of a 2" baader clicklock SCT onto the eyepiece side of the diagonal - giving me the very nice clicklock mechanism I was after to hold my eyepieces in place. Thank you so much for your help.

May be something like this? https://www.firstlightoptics.com/adapters/baader-microstage-clickstop-digital-camera-adapter.html

My diagonal doesn't have a compression ring - just 2 screws that poke through the barrel and directly grip the EP nose. I'm pretty careful and haven't marked my EPs yet; nor had any fall out; but I know the time will come when I'm all excited to change by EP to take advantage of some perfect seeing and I'll have an accident. I've found a 2" Bresser 35mm Extension Tube that terminates in a compression ring or a 2" Altair 50mm Extension Tube that has a Positive Lock. But it doesn't feel right to add 35mm or 50mm to the light path when I don't 'need' to. Am I worrying over nothing?

I'm a newbie just getting to grips with my new equipment. I want to hold my 2" eyepieces in my 2" diagonal with a twistlock or similar mechanism - rather than the 2 screw method that came as standard because that seems less secure, harder to centre and might mark my eyepieces. Is there an adaptor that will do this? I've seen 2" to 1.25" but not 2" to 2". And if they do exist, will it add too much to the light path making focusing harder in some cases? Or is my only/best option to replace my diagonal with one that has a twistlock built in? And on that note, I don't know if my diagonal (that came with the scope) is any good anyway and maybe "should" be replaced? It's a Celestron 2” mirror diagonal #93519 that doesn't appear to be a current model so I can't find out anything about it. My scope is a Celestron 8" Edge HD. Advice gratefully received.

There are lots of trees at Brown Moss. There is a good clearing but it would be difficult to lug everything there from the car park. I wondered about Whixall Marina car park - but imagine you'd need permission and I'm not sure it would be forthcoming with nothing in it for the owners. Thank you all for your suggestions