437 replies to this topic

[ThatsMyCoffee]

I've used Mark Jordan's Stardeck page as well - very helpful.  Do let us know how guiding goes for you when next you're able to get out.

 

Guiding continues to elude me.  My OAG no longer seems to be in focus with the main cam and some bad seeing meant that I kept losing my guide star.  Resulting images were a mess.  Threw away 75% of the subs I took last night, but still got a very noisy low-quality image out of it.  Honestly amazed I can see anything with 14 minutes of total exposure time!!

 

One big surprise after the mount tuning:  My first alignment star was in my field of view.  I don't recall this *ever* happening before.  And nearly centred.  Wow.  I hope that continues!

 

NGC 7000

 

Edited by ThatsMyCoffee, 01 July 2019 - 02:18 PM.

[Devonshire]

If the conditions (seeing, clouds, wind, whatever...) don't cooperate, not much you can do.  Those are my 'testing' nights, if I go out at all. 

 

I'm not surprised that your mount benefited from some work.  Mine certainly did, and those Stardeck pages, while not fully applicable, were still good enough to show me what I was getting into.  A bit of thoughtful work and adjustment, and it was like night and day.

[nmk456]

If you're running the POTH hub before doing anything else, you should see correct coordinates there.  If you don't, then you have an issue.

I wasn't before, but I tried connecting the mount to POTH and APT to that. It still doesn't work. The handset will show whatever coordinates it's pointed at and will respond to a GOTO command in APT, but POTH and APT both show zero for all the coordinates.

[ThatsMyCoffee]

I wasn't before, but I tried connecting the mount to POTH and APT to that. It still doesn't work. The handset will show whatever coordinates it's pointed at and will respond to a GOTO command in APT, but POTH and APT both show zero for all the coordinates.

 

Before complicating things by using APT, try just the POTH hub by itself.  Mine did the same (showing zeroes) until I changed something.  I just don't remember what the something is.....   Don't give up!   I remember going step by step through the (horrible) instructions from the Bresser firmware upgrade.  I'd go through them again, if I were you.  Not the firmware part, just the connection instructions after that.

[nmk456]

Before complicating things by using APT, try just the POTH hub by itself.  Mine did the same (showing zeroes) until I changed something.  I just don't remember what the something is.....   Don't give up!   I remember going step by step through the (horrible) instructions from the Bresser firmware upgrade.  I'd go through them again, if I were you.  Not the firmware part, just the connection instructions after that.

Can you share a picture your POTH advanced settings? I uncheck a bunch of the options under "Scope Capabilities", and now it displays coordinates, but not the correct ones. I can't figure out which of the options to check to get the correct coordinate, but there probably is some combination that works.

[ThatsMyCoffee]

Can you share a picture your POTH advanced settings? I uncheck a bunch of the options under "Scope Capabilities", and now it displays coordinates, but not the correct ones. I can't figure out which of the options to check to get the correct coordinate, but there probably is some combination that works.

 

I'm working from memory, since I no longer use Windows.  But I think I didn't change anything in those advanced settings.  Just used the default values.  Mostly because I didn't understand them.

 

Can anybody else help?

[ThatsMyCoffee]

I've been saving from a long time now to buy a new mount and get rid of this one.  The day has finally come:  My new SkyWatcher HEQ5 with the Rowan belt drive upgrade is on the way from FLO.

 

Many thanks to those that tried to help me on this journey.  I learned a lot, despite all the frustrations.

 

I did have one final victory I'd like to share.  I managed to get rid of that annoying BEEP!  I opened the handset and cut the lead to the speaker.  I thought it might destroy the handset, but I'm at the point where I didn't care anymore...  It worked!!  Total silence.

[PatrickVt]

I did have one final victory I'd like to share.  I managed to get rid of that annoying BEEP!  I opened the handset and cut the lead to the speaker.  I thought it might destroy the handset, but I'm at the point where I didn't care anymore...  It worked!!  Total silence.

 

That beep has always annoyed me, annoyed my wife, annoyed my neighbors.  I tried covering the speaker with foam tape but there was no difference.  Just recently, I filled the hole in the speaker with Gel CA glue...  reassembled it...  let it dry overnight...  now there is only an almost inaudible beep like you hear during a hearing test.  

 

On a sidenote...  best of luck with your new HEQ5.  

 

Patrick

[Spitzbube]

Hi all,

 

I would like to inform you that I have recently started to analyze the firmware for the EXOS-2 controller to find out how they implemented things (like e.g. the annoying beep but also the ASCOM interface via UART).

I already made some progress so that I can even build my own firmware with basic functions like access to the object database in the flash and all the menu pages.

The far goal would be to enable the USB port and also the card slot in the controller. At the moment these peripherials are not available by the official firmware simply because there is no more space in the processor's flash. On the other hand the firmware is not at all optimized (not even by the compiler settings ).

 

If anyone is interested, you can find my results here: https://github.com/S..._HandController.

The official firmware was build using a special ARM compiler and (due to its size) requires a license.

I have already added also a Makefile for the GNU compiler and I hope to provide the sources also buildable completely with free tools.

 

If all this sounds interesting, please let me hear your ideas.

 

Thomas

[alienmatos]

Sounds interesting...  nice to see somebody actually hacking and sharing it with the community.. Plese keep us updated, i dont have my mount with me since im away from home, in february ill give a try, meanwhile ill keep both eyes on this Topic

Hi all,

 

I would like to inform you that I have recently started to analyze the firmware for the EXOS-2 controller to find out how they implemented things (like e.g. the annoying beep but also the ASCOM interface via UART).

I already made some progress so that I can even build my own firmware with basic functions like access to the object database in the flash and all the menu pages.

The far goal would be to enable the USB port and also the card slot in the controller. At the moment these peripherials are not available by the official firmware simply because there is no more space in the processor's flash. On the other hand the firmware is not at all optimized (not even by the compiler settings ).

 

If anyone is interested, you can find my results here: https://github.com/S..._HandController.

The official firmware was build using a special ARM compiler and (due to its size) requires a license.

I have already added also a Makefile for the GNU compiler and I hope to provide the sources also buildable completely with free tools.

 

If all this sounds interesting, please let me hear your ideas.

 

Thomas

[mabdinur85]

Hi all,

 

I would like to inform you that I have recently started to analyze the firmware for the EXOS-2 controller to find out how they implemented things (like e.g. the annoying beep but also the ASCOM interface via UART).

I already made some progress so that I can even build my own firmware with basic functions like access to the object database in the flash and all the menu pages.

The far goal would be to enable the USB port and also the card slot in the controller. At the moment these peripherials are not available by the official firmware simply because there is no more space in the processor's flash. On the other hand the firmware is not at all optimized (not even by the compiler settings ).

 

If anyone is interested, you can find my results here: https://github.com/S..._HandController.

The official firmware was build using a special ARM compiler and (due to its size) requires a license.

I have already added also a Makefile for the GNU compiler and I hope to provide the sources also buildable completely with free tools.

 

If all this sounds interesting, please let me hear your ideas.

 

Thomas

 

Hi Thomas;

 

I think it's a great idea trying to load this handbox with custom firmware since there is room for improvement. Also the open source tools and info we can glean from the board itself lends itself to such an activity.

I think attempting USB control and SD Card support is an unnecessary tall order that has little return on effort. If we have serial support then USB is a complexity that isn't required and the SD card doesn't have a socket and I'm not sure if the connections properly terminate back to the MCU ... furthermore I think if you get the SD SPI working it means you lose the 16Mbit NOR Flash that is already available. I also think they didn't bother because they ran out of the 512KB internal memory headroom; just my speculations from giving the board a look. I think a more adventurous addition might be to use that SD Card area for a BT Serial Transceiver to aid in going wireless?

 

What I think can be improved is ease of usability, alignment reliability, probably UI, controlling audio, maybe add PEC, full LX200 protocol compliance, computer interoperability through ASCOM/ INDI, PHD2 Guiding support, create different motor drive versions (stepper/ servo), etc...

 

I also see in the GitHub link you have a FreeRTOS port for LPC2148. I like the idea of using a RTOS and I'am looking at NuttX which also supports the MCU. I can't tell which is a better route at this point although NuttX does support the graphics LCD, has a framebuffer driver, motor control library, RTC support, audio/ tone generator support, and the NOR Flash is also supported downside is documentation is not the best and the board level implementation doesn't exist ... but using another LPC2148 board implementation called MCU-123 LPC2148 development board as a template I think we can implement/ port NuttX for the handbox. Once an RTOS is loaded then app development for the controller is simplified. I think something like the rDuinoScope Arduino implementation can be made into a handbox app using the built-in peripherals. An RTOS also makes the application a little more hardware agnostic as the lower level hardware is abstracted from the OS services available to the application.

 

Anyways I think these ideas are ambitious but doable. Although I think the primary efforts should be into understanding the netlist for the board ... at least the MCU to Peripherals connections. I have started a spreadsheet outlining these connections for the SkyVision rev 1.09 model which is what my handbox is. This is ongoing and others can contribute, verify and or correct. I also mapped the 5x4 matrix 20 character keypad ... which is how they are connected to each other not how they are connected to the MCU so the row and column numbering is arbitrary ... the MCU connection is yet to come but somebody else can do that. In my board one of the crystals is easily identifiable as 11.0592 MHz and it's connected to the system clock pin, the serial connection setting instruction says 14.745MHz, and the other crystal is for the RTC but is obstructed from my view yet I think it's ~32kHz ... I have to examine the datasheet to understand the clocking discrepancy. The handbox also has a unicode character generator which has a Chinese language datasheet. Since it interfaces between the board and the GLCD ... it might be an issue. The GLCD also has a completely Chinese language datasheet but in reality the driver is ST7565R which has documentation and is supported on NuttX. I haven't yet mapped all the connections like LED's to the MCU; maybe others can contribute and I'll update it depending on free time but feel free to host the spreadsheet on the your GitHub for others.

 

 LPC2148 Netlist.ods   13.78KB   5 downloads

Edited by mabdinur85, 15 December 2019 - 08:15 PM.

[Spitzbube]

Many thanks for your reply.

Just a quick note, I am currently checking how the SPI0 is multiplexed for both the flash and the display. It seems that SPI1 is exclusively used for the SD card socket.

In file_1f30.c::func_2328() you can derive how the pin mux is configured.

maybe others can contribute and I'll update it depending on free time but feel free to host the spreadsheet on the your GitHub for others.

 

[Spitzbube]

 

Just a quick note, I am currently checking how the SPI0 is multiplexed for both the flash and the display font ROM. The GLCD display is independently controlled by GPIO lines.