Print

[TCWORLD]

Grr. Still doing the same thing.

I went searching again and found an even newer version of ControlP5 which is properly patched to not produce that error - any out of bounds characters are converted to a space which should not cause the exception. Trouble with the new version is there were major changes to its APIs, so I've had to change a fair chunk of the utility to make it compatible. Hopefully it was worth it - could you try the new Debug version of the utility (attached in the earlier post) and hopefully this time it will work  .

[doramason]

Grr. Still doing the same thing.

I went searching again and found an even newer version of ControlP5 which is properly patched to not produce that error - any out of bounds characters are converted to a space which should not cause the exception. Trouble with the new version is there were major changes to its APIs, so I've had to change a fair chunk of the utility to make it compatible. Hopefully it was worth it - could you try the new Debug version of the utility (attached in the earlier post) and hopefully this time it will work  .

Yes this time it is working many thanks for your effort, I owe you a pint 

One thing I have noticed; after updating the firmware next button and all other buttons are unresponsive. I need to close astroeq and reopen to configure. Weather is bad so I am trying indoors and so far everything else works ok.

[TCWORLD]

Does anything show in the debug when it freezes after programming?

[doramason]

Does anything show in the debug when it freezes after programming?

I'm attaching.

[TCWORLD]

Can't see anything immediately wrong. I've corrected what might be a bug, but not sure that it will cause the problem you are seeing. If the new version of the AstroEQDebug (attached to the earlier post) doesn't fix it, I think we'll just have to accept that it isn't completely working for you (works fine for me). At least the most important bits are up and running and you can at least launch the utility.

[doramason]

Can't see anything immediately wrong. I've corrected what might be a bug, but not sure that it will cause the problem you are seeing. If the new version of the AstroEQDebug (attached to the earlier post) doesn't fix it, I think we'll just have to accept that it isn't completely working for you (works fine for me). At least the most important bits are up and running and you can at least launch the utility.

Yes it worked this time config utility opened, thanks again for your interest in solving my problem.

I have an unrelated question, when I was trying my setup with 0.9 degree steppers it says in a warning "ival is small, non-sidereal speed accuracy reduced". Does that mean I will have accurate sidereal speed/tracking but when I slew from one object to another lets say 60x sidereal it might not have accurate speed? So in cartes du ciel it might not perfectly center objects? 

[TCWORLD]

The speed at sidereal will be accurate, but the speed at say 60x may be something like 58x or 62x. The distance travelled will *always* be accurate. So unless you are trying to track something moving at high speed it shouldn't matter.

[Jagho]

Test 1
I was testing 7.5 version with DRV 8825 first.  Everything seems to work fine like @ 7.4 version

Test 2
I changed DRV8825 to DRV8834 on the board and changed DRV882x to DRV8834 in the firmware.
Power supply - 8 volts. Vref = 0.65V for my 1.4A stepper motors.
The first strange effect - stepper motors sound is heard BEFORE I run EQMOD (when I turn on the computer or plug USB). This sound takes only 1-2 seconds. Then I turn on EQMOD, another 1-2 sec. noise. Now, I have got EQMOD panel and I try to move S,E,N or W. Nothing happens. Even the RA and DEC coordinates on EQMOD window are not reacting to my pressing.
When I try to run AstroEQ Firmware Update Utility again. I've got messages: "Read Suceeded. EEPROM Blank or Corrupt!" and then "EEPROM Repaired. AstroEQ Ready for Configuration."

Test 3
DRV8834 on the board but I changed DRV8834 to DRV882x in the firmware. It "works" but motors sound very strange, louder and it seems to me the mount is slewing little slower.

[TCWORLD]

@Jagho, Thanks for the feedback. I'll have a look into why the DRV8834 doesn't work yet.

Might seem a daft question, but did you upload the new firmware (from the first post of this thread)? I can't seem to recreate the EEPROM corrupt issue. It makes sense that it would happen if it was the old firmware because it wouldn't recognise the motor driver, but should be fine with the new firmware.

[Jagho]

Yes, I've got AstroEQ7-ConfigUtility.zip file from the first post of this thread.

otherwise I would not be able to set DRV8834 in the firmware.

[TCWORLD]

I figured you had the utility, it was just whether you had use the Upload Firmware button to load the beta firmware. Might be worth doing that again even if you already have just to make sure it is definitely on there.

[Jagho]

Oh, I see, Tom.
I'll try to do so tomorrow and let you know.

[Jagho]

I've got some progress, after firmware updating.
So, there's not "...EEPROM Blank or Corrupt!" message and even EQMOD is working properly and slewing but only some 30-40 seconds. Suddenly, it stops and there's no reaction like in the previous TEST 2.
I still have these 1-2 seconds sounds from motors while turning on the system. It's not a problem but I mention this because it perhaps may be a clue (or not )

DRV8825 board with DRV882x config settings still works properly.

[TCWORLD]

@Jagho
I wonder if the lower supply voltage coupled with transients created by the motors is causing the +5V line to drop out and reset the ATMega.

[Jagho]

@Jagho
I wonder if the lower supply voltage coupled with transients created by the motors is causing the +5V line to drop out and reset the ATMega.

OK, Tom,
I'll try to increse the voltage to 10.8 V (max for DRV 8834) and see what will happen.