Beiträge von mkossmann

Das gleiche Problem ( letzte drei Zeichen der GeräteID fehlen im GUI) gibt es auch auf dem einem Aventura 2020 mit 5.0.4 ( build 202107290843) . Dort ist RegInfo.ini dann im AppData Verzeichnis zu finden. Ist das ein Bug ( und damit ein Ticket wert) oder Firmenpolitik ?

Den oben verlinkten Test einiger aktueller Geräte hast du gesehen ?

Es hat sich inzwischen der deutsche Support gemeldet und über den Twonav -Amazon-Shop komme ich an ein Ersatzgerät ohne Kreditkarte oder Paypal-Account

Hmm, damit wird es wohl nichts mit der Reparatur meines Aventura 2018 bis zum Beginn meines Urlaubs in 2,5 Wochen. Ein neues Gerät im Online-Shop zu bestellen geht aber auch nicht, da ich weder passende Karte noch PayPal-Account habe um bezahlen zu können. Und in Preisvergleichsportalen sind auch keine Händler mit ausreichend guten Bewertungen zu finden.

Ich habe am Sonntag zwei Anfragen auf Deutsch an den Twonav Support gestellt und bis heute keine Antwort erhalten.

Ist das normal oder liegt das eventuell an der Ferienzeit ( Urlaub des deutschspachigen Supports) ?

Zitat von spaziergaenger

Kommerzielle Karten sollten ihre Daten hierzu aber nicht über irgendwelche User einsammeln, sondern auf amtliche Datenbanken der Straßenverkehrsbehörden zurückgreifen können, da es zu jedem offiziellen Geschwindigkeitsschild mit Sicherheit ein Menge Verwaltungsakte gibt.

Da wäre ich mir nicht so sicher. Leute, die gegen benutzungspflichtige Radwege vorgehen, mußten schon öfters feststellen, das keine Akte zu dem betreffenden Schild aufzufinden war.Regelmäßige Verkehrsschauen, die die Beschilderung überprüfen, finden aus Personalmangel oft auch nicht statt.

Zitat von RainerSurfer

Auch Lion gab es bisher nur beim Montana (und GPSMap66 ?) , aber selbst da kann man AA alternativ verwenden.

Das 66i hat einen festeingebauten LiON Akku .

Zitat von chrisl

Da ich die Entwicklung der letzten Jahre nicht mitverfolgt habe an dieser Stelle die Frage - was hat sich denn an Navigationsgeräten in den letzten 10 Jahren eigentlich verändert? Wo finde ich denn einen (wieder-) Einstieg?

Änderungen in den letzten 10 Jahren

"MultiGNSS". D.h. Es können neben GPS auch die Gallileo und Glonass Satelliten benutzt werden .

Anbindung nach aussen: Serielle Schnittstellen sind tot, neben USB sind neu dazugekommen WLAN,BT und ANT+ ( für z.B Herzfrequenzsensoren) .

Stromversorgung : Man setzt statt auf AA/AAA Zellen stärker auf LiON Akkus., teilweise auch festeingebaut

Tests aktueller Geräte findest du neben dem oben angepinnten auf z.B. auf navigation-professionell.de

https://www.poibase.com/ zeigt im Moment bei mir keine Probleme.

Laut http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-3-1-4-RC1-available-td5448077.html

gibt es proj_crs_get_datum_ensemble erst seit PROJ 7.2. Könnte es sein, das es auf deinem produktiv PC neben der neugebauten libproj noch eine weitere, ältere Version gibt ?

Nein das dürfte nicht der Fehler sein. Denn libpthread ist Teil des glibc Paketes.

Wenn das Testprogramm (hier auf Opensuse Tumbleweed ) mit den gleichen Compiler-Flags compiliere wie im PROJ Buildsystem bekomme ich auch den gleichen Fehler

>gcc pthreadtest.c -o pthreadtest -rdynamic 
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: /tmp/ccDrVsAu.o: in function `main':
pthreadtest.c:(.text+0x2d): undefined reference to `pthread_create'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: pthreadtest.c:(.text+0x39): undefined reference to `pthread_detach'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: pthreadtest.c:(.text+0x45): undefined reference to `pthread_cancel'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: pthreadtest.c:(.text+0x56): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status

Wenn ich aber mit libpthread linke

 > gcc pthreadtest.c -o pthreadtest -rdynamic -lpthread

oder als gcc Spezialität das Flag -pthread verwende:

gcc -pthread pthreadtest.c -o pthreadtest -rdynamic 

läßt es sich einwandfrei bauen

Leider kann ich aber nicht weiterhelfen wie man dies fixt.

trailsucher

Das Problem ist anscheinend das dieses Testprogramm :

#include <pthread.h>

void* test_func(void* data)
{
  return data;
}

int main(void)
{
  pthread_t thread;
  pthread_create(&thread, NULL, test_func, NULL);
  pthread_detach(thread);
  pthread_cancel(thread);
  pthread_join(thread, NULL);
  pthread_atfork(NULL, NULL, NULL);
  pthread_exit(NULL);

  return 0;
}

nicht gebaut werden kann. Das Versuch das Programm zu bauen ergibt folgendes Ergebnis :

/usr/bin/ld: CMakeFiles/cmTC_359c3.dir/src.c.o: in function `main':
src.c:(.text+0x2f): undefined reference to `pthread_create'
/usr/bin/ld: src.c:(.text+0x3b): undefined reference to `pthread_detach'
/usr/bin/ld: src.c:(.text+0x47): undefined reference to `pthread_cancel'
/usr/bin/ld: src.c:(.text+0x58): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status. 

Komisch dabei ist , das er nicht auch wegen pthread_atfork und pthread_exit meckert.

Kannst du den obigen Quellcode mal manuell kompilieren ?

Also in eine Datei pthreadtest.c abspeichern und dann mit

gcc pthreadtest.c -o pthreadtest -rdynamic -lpthread kompilieren.

Gibt es da den gleichen Fehler ?

Da pthreads Teil des libc6 Paketes sind. Gab es da zwischen dem letzten erfolgreichen Bau und heute ein Update ?

Zitat von Reinhard#32

Ich habe vor geraumer Zeit mal irgendwo gelesen, dass das Autorouting für Kraftfahrzeuge auf OSM Karten entfernt wird.

Es scheinen Haftungsgründe zu sein. Garmin kann nicht garantieren, dass das Routing auf OSM Karten verkehrsrechtlich sauber funktioniert.

Und bei kommerziellen Karten ist das garantiert ?

Nein, da liegt das Haftungsrisiko dann wohl beim Anbieter dieser Karte und nicht mehr bei Garmin.

Bei diesen USB GPS Mäusen wurde der USB-Seriell Wandler einfach in das Gehäuse der Maus integriert.

Braucht also auch einen Fake-Comport-Treiber

Zitat von Etrexbastler

muss ich Windoof nur wieder verklickern das er diesen unsignierten bösen Treiber auch läd

Es gibt bei Prolific auch aktuelle WHQL Treiber.

Aber die brauchst du ja nicht mehr.

Wenn das Programm wirklich nur mit den "alten" DOS Port-Adressen 0x3f8 und 0x2f8 und den IRQs 3 und 4 zurechtkommt , dürfte es auch Probleme mit PCI(e)-Erweiterungskarten bekommen. Da dürfte dann nur eine VM helfen die emulierte Ports mit diesen Adressen bereitstellt.

@Etrexbastler : Kannst du mehr zu dem Programm sagen,

Was erwartet dieses Programm genau ?

Kommt es mit Daten im im NMEA Format zurecht ?

Wenn ja:

Das 60Cx kennt doch noch den "Spanner" Mode. Vielleicht hilft Spanner /GPS gate Client. Das sollte zumindest bis XP bzw. 7 32bit eine virtuelle serielle Schnittstelle erzeugen, die Daten im NMEA Format bereitstellt.

In Windows 10 gibt es die Location API, die da möglicherweise dazwischenfunkt und ein per USB angeschlossenes GPS eventuell selbst übernimmt.

Da hilft, befürchte ich, nur noch das kommerzielle GPS Gate Splitter.

Ein USB auf Seriell Wandler tut es nicht ?

D.h. der Wandler wird in einen USB Port des PCs gesteckt und die Treibersoftware des Wandlers "erzeugt" einen weiteren "virtuellen" seriellen Port.

Du hast schon in den oben angepinnten  Test geschaut ?

Da werden Alternativen zum Oregon vorgestellt.

Möglicherweise sagt dir eine zu.

Zitat von drevi

Apple verbaut mit M1 derzeit definitiv immer noch Thunderbolt 3

Wenn du nur meinst : Noch kein TB4 bei Apple. Ja , da sind wir uns einig. Aber Windows basierte Laptops mit  TB4 sind schon auf dem Markt.

Zitat von drevi

Thunderbolt 4 ist meines Wissens noch nicht raus

Doch, Z.B Intel JHL 8540 und JHL 8440. Oder in "Tiger Lake" Notebooks

Thunderbold4 = USB4 im "Vollausbau" und somit auch rückwärts kompatibel zu älteren USB Versionen.

Somit sollte es ein beliebiges USB Kabel mit einem USB-C Stecker für den MAC auf der einen Seite und dem passenden USB-Stecker für das Navi auf der anderen Seite tun.