mini Oscilloscopio con mini COM USB

Ottimo Luca,

da alcune prove preliminari sembra ok.
La nuova struttura aiutera´ le impostazioni on the fly.
In questi giorni ho lavorato anche un po´sulla GUI (cerco di strappare un po´ di tempo alla sera).

Ho implementato la modalita´ oscilloscopio ma devo toccare delle cose per diminuire del flickering sulla traccia e pulizia dello schermo. Comunque ci siamo quasi per la versione beta che ti posso spedire.

Una domanda.
Ho visto che in modalita´ oscilloscopio alcune volte si invertono i canali, ovvero ogni volta che richiedo un nuovo buffer, dopo 10-20 buffer mi viene invertito il canale.

Avevo questo timore e nelle specifiche avevo messo che ad ogni richiesta del buffer bisogna inviare nuovamente il codice 55 AA in maniera da mantenere i canali sempre allineati. Mi sembra che questo non sia fatto nella versione attuale del firmware, e da uno sguardo veloce alla GUI credo che neanche dal lato mio lo abbia fatto.

Se implementiamo entrambi la specifica credo che si risolvera´ il problema di inversione dei dati.

Un altro problema che sto riscontrando e´ ad alte velocita´ di campionamento >= 1KHz sembra che i dati non siano corretti, la forma d´onda visualizzata non e´ corretta. Non sono certo dove sia il problema, per ora ho immaginato che lo stack USB possa interferire con velocita´ elevate ma bisognerebbe rifare un test con un file excell per vedere se il problema e´ dal lato GUI o firmware. Fino a 500Hz tutto funziono bene.
Questo non e´ ancora un problema grave, per ora mi sto focalizzando sulla modalita´ oscilloscopio.

Hai avuto modo di leggere il file delle specifiche?

In questi giorni ho pensato anche ad una nuova funzione utile negli oscilloscopi, ovvero il trigger delay, che permetterebbe di vedere i dati prima del trigger. Mettero´ i dettagli nella nuova versione delle specifiche.

Saluti,

Mauro

Ho letto la specifica anche se non mi sono messo per il momento a implementarla alla lettera. Per ora stò cercando di implementare alcune funzioni che possano permettere poi l'implementazione delle varie specifiche. comunque mi era comploramntee sfuggito il cambio di specifica per l'invio del nuovo buffer. Lo implementerò al più presto.
Per i campionamenti ad alta velocità devo verificare, ma potrebbe succedere che se per qualche ragione il timer scatta mentre lo stack stà inviando i dati potrebbe creare dei problemi di trasmissione.
Per il trigger delay, molto utile, devo implementar e un buffer per la memorizzazione dei dati da inviare, che non è un problema (spero), ma a me viene in mente che si potrebbe anche prevedere l'oversampling. Queste funzionalità richiederebbero di non trasmettere il dato appena viene letto ma di trasferire il buffer una volta riempito, giusto?.
Saluti
Luca

Ciao Luca,

il trigger delay richiederebbe un buffer nel quale siano memorizzati i dati prima del trigger.
In base al numero dei campioni richiesti e il valore del trigger delay, sarebbe possibile prelevare una parte dei campioni dal buffer prima del trigger e il resto dal buffer dopo il trigger.
Quindi avresti bisogno di due buffer.

In modalita' oscilloscopio il buffer aiuterebbe a frequenze di campionamento elevate. Infatti la classe CDC indipendentemente dal fatto che tu invii 1 o 50 byte invia sempre pacchetti di 64 byte (se memoria non mi inganna) questo significa che usando un buffer si puo' limitare l'invio dei byte (pacchetti) allo stretto necessario, lasciando piu' risorse temporali per lo stack.

Per quanto riguarda le specifiche non sara' necessario implementarle tutte ma solo quelle che si ritiene interessanti. Sara' importante poter accettare l'array delle impostazioni, e avvertire la GUI se le impostazioni non sono supportate.
...per cui puoi rispondere il 99% delle volte, impostazioni non supportate.

Nei prossimi giorni voglio aggiustare alcuni aspetti grafici e rendero' poi disponibile la versione beta per permetterti di fare i test piu' velocemente.
Prima di questo vorrei implementare anche la funzione per mantenere i canali allineati tra una richiesta di un buffer e l'altra...

Pero' non ti devi spaventare per la versione beta, visto che ogni tanto accadono cose strane...ma ne conosco l'origine, quindi e' solo questione di tempo per eliminarle.

Saluti,

Mauro

Ho modificarto l'invio del buffer inserendo 55 AA alla richiesta, poi ricerca il trigger e inizia a inviare i dati. Non ho fatto una nuova versione in quanto la modifica è minima, rimane sempre 1.5.
Fai caso se l'inversione avviene solo con sample rate alto oppure anche con bassa velocità.
Saluti
Luca

Ciao Luca,

ho testato la nuova versione e opportunamente cambiato la GUI al fine da aspettarsi 55 AA ad ogni richiesta del buffer.

Il firmware continua a funzionare ma sembra che ci siano ancora delle inversioni di canale ogni 20-30 secondi di funzionamento.

...per ora continuiamo ad andare avanti e tenere a mente il problema.
Non so dove possa stare.

la modifica tienila visto che ora la GUI si aspetta l'header dei dati ad ogni buffer.

Saluti,

Mauro