French AStream_NewData et données non régulières

[fgh3966]

Bonjour

J'utilise AStream_NewData pour recevoir des données qui ne sont pas envoyées régulièrement dans le temps, ça fonctionne avec des données assez lentes (inférieure à 19600 baud) mais a des vitesses avoisinant les 115000 bauds le programme freeze completement, le smartphone est figé, bloqué.

Est ce que AStream_NewData est la bonne solution pour lires des données usb rs232 ?

 

[emexes]

a des vitesses avoisinant les 115000 bauds

il serait plus sûr d'utiliser exactement 115200
(c'est-à-dire 19200 x 6)

Traitez-vous les données entrantes sous forme d'octets ou de chaînes de caractères?

Si vous sautez temporairement (commentez) le traitement des données entrantes, le programme continue freeze?

edit: ou, ce qui est peut-être plus simple, "Return" immédiatement au début de NewData Sub

 

[fgh3966]

heu oui c'est bien 115200,
je traites les données sous formes d'octets
Je ne comprends pas votre seconde phrase, j'ai essayé de faire le moins de "tâches possible" , cependant il me faut décoder ces données et les afficher
Ci joint un programme allégé avec un traitement de données qui me semble simple et pourtant ça freeze à 115200
l'usb envoi 19 paquet et si length + buffer(18) + comparaison correspondent le décodage s'effectue et est affiché.

Je vais regarder votre dernière suggestion.
Merci

 

[emexes]

Si vous ajoutez le code Log suivant, que recevez-vous ?

Il se peut que rien n'apparaisse à la vitesse 115200.

Si c'est le cas, pouvez-vous ralentir à 9600 ou 19200 ?

Il serait utile que vous puissiez coller une douzaine de lignes de journal ici, y compris les horodatages pour évaluer le nombre de paquets par seconde qui arrivent.

Je me demande si vous ne rencontrez pas le problème courant des paquets qui sont divisés par le processus USB.

Sub Astreams1_NewData (Buffer() As Byte)        ' bytes received 
Dim bc as ByteConverter
Log(DateTime.Now & tab & Buffer.Length & tab & bc.HexFromBytes(Buffer))
    If Buffer.Length > 18 Then

edit: Activez la bibliothèque ByteConverter dans l'onglet Bibliothèques (si elle n'est pas déjà incluse/utilisée ailleurs dans votre programme).

 

[emexes]

Traitez-vous les données entrantes sous forme d'octets ou de chaînes de caractères?

je traites les données sous formes d'octets

Les protocoles sériels sont le plus souvent au format texte ASCII ou au format binaire.

Le format texte/ASCII est facile à déboguer parce qu'il est lisible par l'homme, mais il est plus long à traiter par l'ordinateur, surtout s'il est traité caractère par caractère à l'aide des fonctions String.

Il est possible que le traitement complexe des chaînes de caractères ne soit pas en mesure de suivre le rythme des données entrantes continues à grande vitesse, mais qu'il puisse suivre le rythme des données à plus faible vitesse.

 

[emexes]

Sub Astreams1_NewData (Buffer() As Byte)        ' bytes received 
  
    If Buffer.Length > 18 Then 
        If Bit.And(0xff,Buffer(18))=252 Then
            fb(0)=Bit.And(0xFF,Buffer(0))
            fb(1)=Bit.And(0xFF,Buffer(1))        'convert to unsigned bytes
            fb(2)=Bit.And(0xFF,Buffer(2))
            fb(3)=Bit.And(0xFF,Buffer(3))
            fb(4)=Bit.And(0xFF,Buffer(4))
            fb(5)=Bit.And(0xFF,Buffer(5))
        End If
    End If

En réfléchissant aujourd'hui à vos données manquantes à des vitesses plus élevées, je m'interroge également sur la structure du paquet.

Il semble étrange que l'octet de synchronisation 252 se trouve à la fin du paquet et que les données du paquet (6 chiffres décimaux à afficher sur les tubes Nixie ?) commencent au premier octet.

Je suis donc très intéressé de voir à quoi ressemblent les données série entrantes.

Disposez-vous d'une documentation sur la structure du protocole série reçu ? Les paquets ont-ils une longueur de 18 octets, ou peut-être de 9 octets, mais la couche USB les regroupe ? On peut supposer qu'ils ne peuvent pas avoir une longueur de 6 octets, car il serait alors difficile de déterminer lequel des 6 octets est le début d'un paquet.

Ai-je raison de supposer que vous construisez un écran Nixie virtuel ?

Spoiler: Original English before translation by deepl.com

Thinking today about your missing data at higher speeds, I'm also wondering about the packet structure.

It seems odd that the synchronisation byte 252 would be at the end of the packet, and that the data of the packet (6 decimal digits to display on Nixie tubes?) would begin at the first byte.

So I am very interested to see what the incoming serial data looks like.

Do you have any documentation about the structure of the received serial protocol? Are the packets 18 bytes long, or perhaps 9 bytes long but the USB layer is bundling them together? Presumably they can't be 6 bytes long, because then it would be difficult to work out which of the 6 bytes is the beginning of a packet.

Am I correct in guessing that you are building a virtual Nixie display?

 

[fgh3966]

Bonjour

Oui je construis un voire plusieurs écrans nixie pour android.

En pièce jointe ( à ouvrir avec wordpad ) voici un log a 9600 bauds et en plus des instructions que vous m'avez donné il y a un log de la variable compte.

la valeur de 252 n'est envoyée qu'une seule et unique fois, elle sert de synchronisation des paquets.
Ensuite il faut calculer le valeur entre elles pour obtenir les résultats qui seront affichés dans l'interface android.

La structure des paquet est de 18 octets de données utiles + 1 octet de synchronisation (252).
L'octet de synchro (252) est à la fin des paquets pour que le programme récupère, traite puis affiche les données des 18 autres octets qui sont stockées dans le buffer avant que le prochain paquet d'octet arrive.
Actuellement je recherche à décoder et afficher les 6 premiers octets, plus tard il faudra décoder et afficher les valeurs 18 octets.

Enfin les données arrivent très rapidement au minimum à 19200 bauds et souvent jusqu'à 576000 bauds. Les paquets de données ne sont pas du tout syncrhonisées dans le temps.

Ce protocole ou couche usb est actuellement utilisé sur PC et des programmes comme hyperterminal, putty , aussi ftdi_uart_terminal pour android permettent de les voire et de les enregistrer.

Peut être qu'il y a un problème de gestion des buffer ?
Les paquets de données arrivent trop rapidement, les buffers débordent et freeze le programme ?

 

[emexes]

576000 bauds

576000???

Je pensais qu'il s'agissait d'une faute de frappe et que le chiffre devait être 57600, mais je me suis ensuite rendu compte qu'il s'agissait d'un multiple entier de 115200 et que c'était donc peut-être correct.

Cela fait beaucoup de bits.

 

[emexes]

En pièce jointe ( à ouvrir avec wordpad )

Le fichier semble s'être échappé lors d'voyage vers la lointaine Melbourne, Australie.

 

[emexes]

Les paquets ont-ils toujours une longueur de 19 octets ?

La valeur 252 se trouve toujours à la fin, dans le 19e octet ?

Et les 18 autres octets n'ont jamais la valeur 252 ?

Si c'est le cas, l'analyse la plus simple pourrait être un tampon circulaire de 19 octets.

Existe-t-il d'autres octets à position et valeur fixes pour faciliter la synchronisation ?

 

[fgh3966]

Oup's pour le fichier, le voici
Le Bonjour à Merlboune ! de la part du sud de la France (34)

Aussi : Oui les paquet ont toujours une longueur de 19 octets et la valeur 252 est au 19e octet.
En effet les autres octets n'ont jamais la valeur de 252 ce qui façilite la synchronisation.
La seule valeur fixe est de 252 elle n'apparaît jamais dans les 18 autres octets.

 

[emexes]

Êtes-vous certain que la valeur de l'octet de synchronisation est 252 (0xFC) ?

Ou bien l'information du journal provient-elle d'un autre appareil avec une valeur d'octet de synchronisation différente ?

1709187211650    19    857F00AA08000F0000122400D2410000F807F9
1709187211682    19    857F00AA0800000000157E00D24100005C00F9
1709187211698    19    857F00AA08000F000018D800D2410000B900F9
1709187211714    19    857F00AA08000000001C3200D34100001800F9
1709187211746    19    857F00AA08000F00001F8C00D34100007500F9
1709187211762    19    857F00AA08000F000022E600D3410000D200F9
1709187211794    19    857F00AA0800000000274000D44100003200F9
1709187211810    19    857F00AA08000F0000299A00D44100008E00F9
1709187211842    19    857F00AA08000F00002CF400D4410000EB00F9
1709187211858    19    857F00AA08000000002F4E00D54100004900F9
1709187211890    19    857F00AA08000F000033A800D5410000A700F9
1709187211906    19    857F00AA0800000000360200D64100000500F9
1709187211922    19    857F00AA0800000000395C00D64100006200F9
1709187211954    19    857F00AA08000F00003DB600D6410000C000F9
1709187211970    19    857F00AA0800000000401000D74100001E00F9

 

[fgh3966]

Normalement sur la carte qu'on m'a fourni il est bien noté que c'est 252.

 

[emexes]

Ceci pourrait faire l'affaire.

Mais à 576000 bauds = 57600 octets par seconde = 3031 paquets par seconde... J'ai pensé que debug logging ou les mises à jour de l'affichage pourraient avoir du mal à suivre, alors j'ai diminué la charge de travail en n'utilisant que le dernier paquet reçu par morceau USB.

Sub Process_Globals
    Dim PacketSize = 19
    Dim Packet(PacketSize) As Byte
    Dim PacketStartsWith() As Byte = Array As Byte(0x85, 0x7F)
    Dim HowManySoFar As Int = 0
End Sub

Sub Astreams1_NewData (Buffer() As Byte)        ' bytes received
    Dim LastPacketValidFlag As Boolean = False

    For I = 0 To Buffer.Length - 1    'process buffer byte-by-byte
        If HowManySoFar < PacketStartsWith.Length Then    'if near start of packet
            If Buffer(I) <> PacketStartsWith(HowManySoFar) Then    'check against expected start bytes
                HowManySoFar = 0    'reset if doesn't match
                Continue    'and short-circuit to next loop
            End If
        End If
     
        Packet(HowManySoFar) = Buffer(I)
        HowManySoFar = HowManySoFar + 1
     
        If HowManySoFar >= PacketSize Then
            Dim LastPacket(PacketSize) As Byte
            For J = 0 to PacketSize - 1
                LastPacket(J) = Packet(J)
            Next
            LastPacketValidFlag = True

            HowManySoFar = 0    'reset for start of next packet
        End If
    Next

    If LastPacketValidFlag Then
        HandleNixiePacket(LastPacket)
    End If
End Sub

Sub HandleNixiePacket(B() As Byte)
    Dim bc As ByteConverter
    Log(DateTime.Now & TAB & bc.HexFromBytes(B))
End Sub

 

[fgh3966]

Bonjour
On essayé plusieurs logiciels de terminal sur PC et smartphones, il y a des problèmes sur smartphone, c'est lié a la rapidité des appareils.
Aussi merci pour ton analyse et les code joins.
Je te tiens au courant.

 

[emexes]

c'est lié a la rapidité des appareils

""

Qu'en est-il en mode Release plutôt qu'en mode Debug ?

Et si tout ce que vous faites dans Sub Astreams1_NewData est d'Log quelques nombres ? Combien de fois par seconde cette routine est-elle appelée lorsque les données arrivent à plein régime ?

Sub Astreams1_NewData (Buffer() As Byte)        ' bytes received
    Log(DateTime.Now & Tab & Buffer.Length)
End Sub

 

[fgh3966]

Bonsoir

Voici un second ( 2nd ) log

En mode realise il faut afficher les infos dans un label ou un EditText, c'est bien ça ?
Je pense que le mode realise est bien plus rapide que le mode log.

J'essaye de comprendre ce que vous avez programmé
Aussi les paquets de 19 octets arrivent tout les 0.5ms, soit 500 microseconde et ça peut déscendre à 0,27ms ( 270 µs )

Remarque : avec un tel débit il faudra déscendre à des paquets de 16 octets sinon passer à la vitesse de 921600 bauds.
Et sachant qu'a 576000 il semble déjà y avoir des difficultées de traitement.

 

[fgh3966]

Je pense que l'instruction : Log(DateTime.Now & TAB & Buffer.Length) affiche la date avec une précision de la milliseconde (ms), ce qui est génial.
Par contre des paquets sont perdus car souvent length = 38 au lieu de 19
J'ai fais des essais en envoyant des paquets toutes les 10 ms, 20 ms et 50 ms et d'après les chiffres du log il y a du jitter. ce n'est pas bon.
Pourtant le phones est un peu vieux mais c'est quand même un Snapdragon 805 - quad cores 2,7 Ghz.
Demain j'essayerais sur un textedit.

 

[emexes]

et ça peut déscendre à 0,27ms ( 270 µs )

Yikes!

Je vais faire un autre essai avec 25 ms.

Je me demande maintenant pourquoi, si vous contrôlez la vitesse d'envoi des données, vous ne la réglez pas simplement à mi-chemin entre la vitesse la plus basse qui est suffisante pour votre projet et la vitesse la plus élevée qui fonctionne sur tous vos appareils.

Ou peut-être ai-je mal compris votre projet.

J'écris quelques questions qui, je l'espère, m'éclaireront.

En attendant, si vous pouviez exécuter ce programme, en utilisant 115200 bauds, et poster 10 secondes ou 100 lignes de sortie Log ici, ce serait utile. Il n'y a pas d'analyse ou de traitement, donc la vitesse du smartphone ne devrait pas être un problème, même en mode Debug.

Sub Astreams1_NewData (Buffer() As Byte)        ' bytes received
    Log(DateTime.Now & Tab & Buffer.Length)
End Sub

 

[emexes]

Ou peut-être ai-je mal compris votre projet.

Si j'ai bien compris, un nombre est envoyé d'un appareil de mesure à un appareil d'affichage. Je pensais que le système complet était une horloge ou un compteur ou un compteur de tension ou de courant électrique.

Suppose que je ne sais rien.

Quel est l'objectif de l'ensemble du système ?

Quel est l'agencement du matériel ?

À propos du canal de communication que nous lisons :

quel est le lien physique ? (câble ? USB ? RSxxx ? radio ? Bluetooth ? Wifi ?)

Quel est le format du protocole série ? (paquets de 19 octets ?)
S'agit-il d'un protocole personnalisé ou d'un protocole tiers ?
(personnalisé = conçu ou mis en œuvre par vous ou votre entreprise)
Existe-t-il une documentation sur ce protocole série ?
contrôlez-vous ce protocole série ?
Qui définit la vitesse (9600, 19200, 115200) des données sérielles ?
qui définit le taux de paquets envoyés par seconde des données série ?