forum.heinrichsweikamp.com

Hallo,

In der 2.26beta haben wir das Verhalten des Safety Stops nochmal geändert - damit ist das Thema für uns aber abgeschlossen. Wer andere Zeiten oder Tiefen möchte, kann das relativ einfach im Code ändern.

http://www.heinrichsweikamp.com/#/de/ostc_2n/firmware/

Hello,

In the new 2.26beta we have adjusted the safety stop behaviour as discussed here. There are no plans to make this configurable via CFs. If someone wants other depths or durations please change this in the code and compile your own hex file.

http://www.heinrichsweikamp.com/#/en/ostc_2n/firmware/


Regards,
Matthias

Thanks for your efforts!

How is the behavior now?

Any plans on when you'll release the next stable firmware?

:S

This is exactly why I like OpenSource so much!

Want something special? DIY!

Hi,

Custom Functions documentation is up to date too.

Die Custom Functions Dokumentation ist auch auf dem neuesten Stand.

Regards/Grüße
Rob

Hi,

anybody tried it yet?
My 2N is not responding after firmware update.
Done through JDivelog,everything went fine,confirmation dialog notified of successful writing of firmware.Since then half an hour passed,computer remains unresponsive with black screen.
(Yesterday I updated Seawooch to v2.25+,that was a mess in all CFs with text covering each other and leaving other places empty,downgraded back to 2.20+.)
Thought HW's version would work better,but how do I go back to latest stable with unresponsive unit?(Didn't try the magnet method yet,as there are some reservations regarding that.)

USB serial port is COM16,bootloader v2 cannot find PIC.Updating via JDivelog doesn't work since I can't press reset on non responding unit.
I have upgraded OSTC Mk.2 through every version starting with v1.5,so definitely I should know what I am doing.

Any ideas?

Cheers,

Richard

A non-responding unit after the update showed successful is unlikely. Just try it again - and now trigger the magnet reset instead of using the reset menu. Note, this will only work with the bootloader v1 or Jdivelog since the bootloader then uses 19200baud instead of the 115200baud when using the bootloader v2.

regards,
Matthias

Matthias,lightning fast answer!


Either the magnet is not strong enough or ...I hope not!
Where do i find strong magnet in Egypt remains a question...

Update showed success in JDivelog,usually there's slight delay before the screen comes up on 2N,or press of any button does it.Not this time.

Cheers,

Richard

Hi there,

here with 2.26 over 2.25 (german version) no problem.
OSTCTools, read, write, accessing profile data no problem.
Savety stop works in simulator.

Regards
Rob

fishwithlungs Wrote:
-------------------------------------------------------
> Either the magnet is not strong enough or ...I
> hope not!
> Where do i find strong magnet in Egypt remains a
> question...

Normal Magnet should work too. Just make sure that you have
plugged in the USB cable and all together hangs on your computer...

scubatinoo Wrote:
> How is the behavior now?

- Show 3min safety stop for no-deco dives>10m
- show stop between 5 and 3m
- remove stop above 3m
- reset stop when descending to 10 again

There is a section "Safety stop parameters" in the definitions.asm where these thresholds can be changed with 1mbar resolution.

regards,
Matthias

DiverM Wrote:
-------------------------------------------------------
> This is exactly why I like OpenSource so much!
>
> Want something special? DIY!


Having said this, I downloaded the source, the IDE, even managed to compile a Hex file without any errors. But when I load that Hex file onto my OSTC, it goes black.

Programming goes fine:

Connected to \\.\COM1 at 115200
HEX: 1 min old, INHX32,18Fcode+cfg, total=82702 bytes.
Searching for PIC ...
Found:18F 4685
Reading HEX file... , Writing flash...
WRITE OK at 18:50, time:41.396 sec

But after this the OSTC goes black. (Reloading the last stable firmware is possible with the magnetic reset and bootloader V1)

I'm compiling Beta V2.27 source. Only changed the safety-stop depths, and after very careful review (as I will only be using OC mode with GF) changed the Beta flag to 0.

OSTC Hardware: 2N Ser# 4807

Matthias,
this is the output of BLD v1.0

Bootloader for HeinrichsWeikamp OSTC,
based on TinyBootLoader, v.1.9.5 written by claudiu.chiculita@ugal.ro
http://www.etc.ugal.ro/cchiculita/softw ... loader.htm
Support: info@heinrichsweikamp.com
--------------------------------------------------------------------------------------------------

Connected to \\.\COM16 at 19200
HEX: 6 hours old, INHX32,18Fcode+cfg, total=82684 bytes.
Searching for PIC ...
Found:18F 4685
WRITE OK at 18:50, time:42.291 sec


but the comp remains black after 20 mins.
Gonna give it another try.

Edit: output now

Connected to \\.\COM16 at 19200
Searching for PIC ...Not found,
ERROR!


Cheers,

Richard

Edit 2: JDivelog : Success!Writing of firmware finished.
2N remains black.

Hi,

The log looks like a perfect update. From here, hard to tell what's happening there. You can try with an older version but this could also be a hardware issue of some kind.

regards,
Matthias

Attached, my custom hex file, and the changed definitions.asm

Maybe you can do a comparison with a hex you compile? could be some ide configuration issue as well. (although I did use the sample workspace included in the source)

Can you first test if the original HEX file from our firmware section works?

Cheers,
Matthias

..\mk2_v226-beta.hex

Connected to \\.\COM1 at 115200
HEX: 0 min old, INHX32,18Fcode+cfg, total=82684 bytes.
Searching for PIC ...
Found:18F 4685
Reading HEX file... , Writing flash...
WRITE OK at 19:28, time:43.187 sec

Result: Black screen

Ok, downgrade to the 2.21 (or 2.25beta, attached) using the bootloader v1 trick above. Maybe I can check this issue with the 2.26beta tomorrow morning...

Cheers,
Matthias

Cheers,

going back to 2.25 for now.That did the trick,thank you.

Richard

..\mk2_v225-beta.hex

Connected to \\.\COM1 at 19200
HEX: 11 days old, INHX32,18Fcode+cfg, total=82678 bytes.
Searching for PIC ...
Found:18F 4685
WRITE OK at 20:30, time:23.775 sec

Result: Functional.

Feel free to ask me to test any other firmwares in resolving this issue, or for any future issues regarding firmware and hardware.

I've uploaded to 2.26 beta. No obvious problems and works ok in a simulated dive.

Regards

Jerry.

Same for me - 2.26 beta seems to work fine, and the safety stop countdown is behaving as intended in the simulator.

Hi,

I think the problem only exists if the 2.25beta was NOT installed before. Should be fine now with the 2.27beta I just uploaded.

Cheers,
Matthias

Hi,

Problem solved then! I'll test it on monday, today and tomorrow I'm off diving.
After tomorrow next dive is planned Wednesday or Thursday.

Cheers,
Martijn

Sorry to bring this up again, but in my opinion the safety stop behavior should be changed. Most agencies, virtually all of them including several technical agencies, recommend a stop depth of 5 meters and it makes absolute sense to also support this in the device.
The way it is implemented now, with a countdown only running in a window of 3-5 meters, one would have to always stay shallower than 5m to complete the stop. That does not make sense.
Making it 3-6 meters makes more sense, or if that is not wanted, 4-6 meters should work nicely. Stops at 3m are nowadays very unconventional anyway...