32 replies to this topic

[rkinnett]

I made a web app for surveying the horizon from your smart phone, specifically to help build horizon files for NINA.  You can pan around and snap coordinates, then save the coordinates as a .csv file which you can then email to yourself or maybe save to dropbox or a network file share.  Then on your PC, change the file type from .csv to .hrz and load that horizonal file in NINA, et voila.

 

Instructions are provided on the open screen.  https://rkinnett.github.io/gyrocam/

 

This javascript application activates your camera to provide a live view and uses your phone's sensors to calculate pointing direction.  This app does not send any camera or sensor data over the internet.

 

Currently only works on iPhone.  Does not work on android, yet.  If anyone wants to help get that working, please DM me.

 

   

[Sean1980]

very cool, will save people a few bucks vs buying the various apps out there for this

[dghent]

very cool, will save people a few bucks vs buying the various apps out there for this

It would still be worth it if this were also just a few bucks. The really nice thing about this is that you don’t need to manually massage the data it produces to put it into the desired format and remove errors such as accidental backtracks. This is super useful if you’re a mobile imager and want a quick horizon file for a new location. The toils and aggravation it saves is worth more than any pithy real cost.

[spereira]

Moving to Astro Software & Computers.

 

smp

[Sean1980]

It would still be worth it if this were also just a few bucks. The really nice thing about this is that you don’t need to manually massage the data it produces to put it into the desired format and remove errors such as accidental backtracks. This is super useful if you’re a mobile imager and want a quick horizon file for a new location. The toils and aggravation it saves is worth more than any pithy real cost.

oh definitely I think I paid 10 eur for an app to do this

[rkinnett]

I wonder what else this could be useful for?  If anyone has ideas, I would love to hear them.  I'm pleased with the interface and would like to reuse it.  The accuracy is only good to about 5 degrees, so maybe not good enough for finding stars or tracking satellites, though it can get you in the rough ballpark.  It might be neat if it could report RA/dec coords, but that would require knowing (locally, not transmitting over internet) the phone's GPS location which I've avoided for this application but could consider for other applications.

[fate187]

Very nice! Can the csv file be used to work with Stellarium?

[rkinnett]

Very nice! Can the csv file be used to work with Stellarium?

I originally hoped so, but after a few minutes of searching, I couldn't find a coordinates-based import method.  Maybe there's a way to do it, and I missed it.  Instead, you can make your own horizon graphic by shooting a panorama and then manipulating it into a specific image format that Stellarium requires.  That looks like fun.

[OldManSky]

Ryan, I will likely never use your app -- I have 360-degree "flat" horizons, and I use Android phones.

But I still wanted to thank you for writing it.  Nicely done!

[rkinnett]

Got it working on android!

[fronk]

Great app, too bad I allready bought Theodolite

[rkinnett]

Great app, too bad I allready bought Theodolite

Ironically, I started down this path specifically because I thought $7 was too much to pay for this simple functionality.  7 programming hours later...   It was fun to program this, in any case, and I learned a lot which makes it worth it, especially if folks benefit from it.

 

You might find this useful even after having paid for theodolite.  It generates a NINA-compatible coordinates file that's a bit easier to handle than what you get from theodolite (according to the one youtube vid I watched).

 

By the way, I find it useful to start screen recording on my iphone before I scan my horizon, that way I can go back to it and see what each break point was trying to avoid.

[Adluginb]

Yes you can save the .hrz file to stellarium also.  There is a YouTube video on where to save the file

[rkinnett]

Aha, thanks for the tip, Adluginb.

 

http://stellarium.so...nal_Line_Method

 

https://www.youtube....h?v=xxHqRRYzdTM

 

Synopsis:

 

1) Find your Stellarium landscapes directory:

<user directory>/landscapes or <installation directory>/landscapes

2) Within your Stellarium landscapes directory, make new subdirectory, call it for example 'my_backyard'.

2.5) You will likely need to modify user permissions of your new landscape directory in order to make and modify files in it.

 

3) Within your new landscape subdirectory, create a file called landscape.ini with following content (adjust to taste):

[landscape]
name = My Backyard
type = polygonal
author = Me!
description = My horizon as viewed from my back patio or something like that.
polygonal_horizon_list = my_horizon.txt
polygonal_angle_rotatez = 0
ground_color = .15,.45,.45
horizon_line_color =  .75,.45,.45

4) Use gyrocam to capture az/el pairs, starting near zero azimuth (north) and scanning in increasing azimuth direction (N-E-S-W-N).  Avoid reversing directions - Stellarium insists on monotically increasing azimuth values.

4.1) Either save coordinates to file or copy the coordinates list to clipboard and paste into an email to yourself, then put the az/el coordinates into a text file named my_horizon.txt within the landscape directory you created.

4.5) Remove all commas (Stellarium seems to want either space or tab between az/el values).  Also remove the first line if it's not numerical.

 

5) (re)Start Stellarium, open View Settings, Landscape, and find your new landscape.

 

6) If it doesn't load (no horizon shown), check your data.  Look for any significant jumps in azimuth.  This bit me the first time.  I had three data points that jumped forward 180 deg.  Not sure why;  I wasn't pointed too close to Zenith.  Possible bug.  Other coordinates seemed fine.

 

 

And here's what my ridiculously constrained view looks like:

 

[EmeraldHills]

Elegant, Ryan. Love this. You did the coding equivalent of programming a new invention on a 3D printer - and then you printed it. Well done.

[rkinnett]

coding equivalent of programming a new invention on a 3D printer

That's javascript (or python) in a nutshell!  

 

Thanks Doug!

[aatdalton]

Hello, I just tried using this on Android and it runs great but doesn't seem to be picking up the Azimuth data correctly. It seems like the sensor only reads correctly if my phone (Pixel 5a running the app in firefox) is aimed straight down - which isn't exaccccctly helpful, haha. The Gx, Gy, Gz all seem to record correct as well so I'm wondering what could be done? I'd love to be able to use this for NINA! Thanks for the work you've put in already.

 

EDIT: It appears this is an issue using firefox. Seems to work fine in chrome mobile.

Edited by aatdalton, 25 January 2022 - 03:26 PM.

[rkinnett]

Sweet! Great to hear you got it working.  I'll add a note in the app about using Chrome if the values don't seem sensical.  Another person reported the same on an older Android.

 

I like your yt channel, by the way!

Edited by rkinnett, 25 January 2022 - 04:28 PM.

[rkinnett]

I previously noted that there seems to be a bug where the app records some azimuth values 180 deg away from the actual pointing direction.  I still haven't looked into that yet but wanted to explain in more detail how to work around it.

 

After rescanning my horizon this week, I tried to import the coordinates into Stellarium (per instructions in a previous post) but it didn't work at first.  Stellarium showed a bunch of garbled lines that didn't make any sense.

 

I then pasted the coordinates into Excel and plotted them, and the problem became clear.  Two data points that should have been in the ~285 to 315 deg azimuth range were recorded down around 105 deg, 180 deg from the correct azimuth.  Again, I don't know yet why this happens.  I'll look into it later, maybe on a rainy day or cloudy night.

 

 

I manually added 180 to the two errant points, et voila.

 

 

Much better..

 

 

If you have any trouble importing your horizon coordinates into NINA or Stellarium, inspect your az/el pairs for azimuth values that are clearly far out of range from their neighbors and add 180 deg to those azimuth values, then try importing again. 

Edited by rkinnett, 16 March 2022 - 07:56 PM.

[rkinnett]

Here's a copy of my my_horizon folder which you can unpack into the landscapes folder in your Stellarium directory (i.e. for me, C:\Program Files\Stellarium\landscapes), then paste in your coordinates over mine.

 

To make Stellarium show just the horizon line without filling in the blocked areas in black, you can change a setting in Stellarium -> Sky and Viewing Options -> landscape -> My Horizon -> Draw only polygon.

Attached Files

•  my_horizon.zip   709bytes   29 downloads

[RedLionNJ]

Sounds like an awesome app, Ryan - thank you for creating this. I was just about to shell out for Theodolite (and I still might) in order to create a 2022 horizon for TSX. I live in a clearing in a forest and those pesky trees keep growing (and occasionally some fall). It's been about three years since I tediously and manually created a representation of my horizon in TSX.

 

I'm not sure what the import file format is, but there's really no good reason for it to be more complex than a set of az/alt pairs, so I'm hoping your app can do the trick for me!

[rkinnett]

Sounds like an awesome app, Ryan - thank you for creating this. I was just about to shell out for Theodolite (and I still might) in order to create a 2022 horizon for TSX. I live in a clearing in a forest and those pesky trees keep growing (and occasionally some fall). It's been about three years since I tediously and manually created a representation of my horizon in TSX.

 

I'm not sure what the import file format is, but there's really no good reason for it to be more complex than a set of az/alt pairs, so I'm hoping your app can do the trick for me!

The TSX manual has a good description of their (rather odd) custom horizon format:

https://www.bisque.c...htm#Horizonbc-9

 

If you DM me your az/el data I can build that file for you.  I don't have TSX to test with though.

[RedLionNJ]

The TSX manual has a good description of their (rather odd) custom horizon format:

https://www.bisque.c...htm#Horizonbc-9

 

If you DM me your az/el data I can build that file for you.  I don't have TSX to test with though.

Thanks for the additional offer, Ryan, but that won't be necessary. I found my existing custom horizon file in TSX (and it's just like the format you hyperlinked to from the manual) and I believe I can interpolate the captured data from your app (and remove the first column) to create the format necessary for TSX.

 

I'll let you know how it goes!  

 

Grant

[RedLionNJ]

Thanks for the additional offer, Ryan, but that won't be necessary. I found my existing custom horizon file in TSX (and it's just like the format you hyperlinked to from the manual) and I believe I can interpolate the captured data from your app (and remove the first column) to create the format necessary for TSX.

 

I'll let you know how it goes!  

 

Grant

It worked - perfectly!  Not that you likely plan on marketing this, but you could add a "TheSkyX" format button to it somewhere to make the (interpolated) saved format compatible as-is

 

Seriously, though - awesome. Thank you, Ryan!

 

The next $7 beer is on me

 

Grant

[rkinnett]

 That's awesome, thanks for letting us know it worked.

I have learned a lot from you and others about imaging planets and I'm happy to contribute back in a small way.

 

For future readers, how did you do the interpolation work?  Excel, google docs, python, by hand, etc?

 

It is a good idea to build that interpolation into this web app, and more generally it would be awesome if this could be one-stop-shop for building horizon files for each of the major planetarium and telescope control platforms, but tailoring output to specific applications and building neat UI around it would be a pretty substantial endeavor, more than I can commit to on my own.  I prefer to keep this web app simple and have the output strictly represent captured measurements.  We can separately provide guidance (here in this thread and maybe later in a served page or wiki or google doc) for how to shoehorn the az/el data into formats needed for various applications.  Sorry, I know this kinda takes the oomph out of the usefulness of this app.  I have a lot going on at the moment, including a baby due in 3 weeks!

 

Cheers!