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) ?
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) ?
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.
Auch Lion gab es bisher nur beim Montana (und GPSMap66 ?) , aber selbst da kann man AA alternativ verwenden.
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
oder als gcc Spezialität das Flag -pthread verwende:
läßt es sich einwandfrei bauen
Leider kann ich aber nicht weiterhelfen wie man dies fixt.
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;
}
Alles anzeigen
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 ?
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
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.
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.
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.
Ich würde da zuerst mal versuchen ob man mit z.B. Google Maps oder Here we go auf meinem Smartphone die gewünschte BT-Koppelung realisieren kann. Und wenn das wie gewünscht klappt , eine ordentliche Halterung mit Stromversorgung für das Smartphone besorgen.
ZitatRouting
Was erwartest du vom Routing ? Mehr als den kürzesten und damit schnellsten Weg zu einem Ziel wird es dir nicht zeigen können. Eine "schöne" Wanderroute zu finden geht nicht automatisch.
ZitatVielleicht dann etwas weniger kompakt und dafür günstiger?
Weniger kompakt heißt größeres Display und damit eher teurer
Fehler in den Kartendaten ? Fehlt möglicherweise irgendwo die durchgängige Verbindung über die B3 ?
Was passiert wenn du einen Zwischenwegpunkt setzt ? Z.B. an der Kreuzung , wo es rechts zur Autobahnauffahrt geht.
Und kannst du ausschließen, das da ein Abschnitt für Motorradfahrer gesperrt ist ?
ToKiDo: Autostrassen(östr.) = Kraftfahrstrassen in D. Und das ist nicht identisch mit Bundesstrasse.
Ist an diesem Gerücht:
irgend was dran ?
Ich sehe aber ich die "anderen Höhen" als Hauptproblem, sondern eher eine vermutlich nicht vorhandene genaue Atomuhr in den Satelliten und die noch nicht vorhandene Empfängertechnik.