target nanoSPEC

[marvin]

Guck ich mir alles mal an!

Inzwischen bin ich hierauf gestoßen:
Gamma-MCA

Ich habe mich dann man hingesetzt und das Einlesen der Werte für den nanoSpec modifiziert.

Sieht das hier irgendwie sinnvoll aus?

Sie dürfen in diesem Board keine Dateianhänge sehen.

[wrdmstr inc.]

@NuclearPhoenix kann da bestimmt was zu sagen ,imo sieht das spektrum selbst wenns links komprimiert ist nicht sinnvoll aus 
Laesst sich das evtl in sandia labs interspec importieren?
https://github.com/sandialabs/InterSpec

[marvin]

Ich muss mir wohl tatsächlich mal irgendeine Strahlenquelle besorgen. Eine Schweisselektrode oder einen Glühstrumpf zu besorgen sollte ja kein Problem sein.

Kann mir mal jemand ganz kurz übersichtsweise erklären wie ich die spektrumdaten zu verstehen habe?

Ich verstehe das im Moment so, dass die "Kanäle" eines MCA im Prinzip ein Energie Raster sind, die um 1 erhöht werden, wenn ein Teilchen mit einer bestimmten Energie ankommt. Im "Pulshöhen Analyse Modus"...

Das nanoSpec hat 2048 Kanäle, und in der Kalibrierbeschreibung steht, dass man bei Cs-137 bei 30keV und 662keV einen Peak sehen sollte, wobei die 662keV ungefähr bei Kanal 330 sein soll.

Heisst das dann, dass bei Kanal 15 dann der 30keV Peak ist? Und bei Kanal 2048 theoretisch 4MeV?

[wrdmstr inc.]

stell ich mich grad an oder putty streikt
ich clicke doch  links auf serial ,zb com4 ,19200,8, 1, none, xon/xoff und DTR Kabel Pin4 auf DTR

und open aber gleich kommt der windows "blimm" sound und nix passiert, müsste er nicht wenigstens was versuchen zu verbinden?

EDIT: ok ich hab mich angestellt  oben ist ja auch noch im menü was auszuwählen (serial), ich hatte nur unten das serial gesehen...aber trotzdem kein mux



ja genau die kanäle sind energieraster ,meist 2kev/kanal also 2048 kanäle =4Mev als letzter und bei 15 dann die 30kev aber das alles NACH dem kalibrieren, vorher weis der das nicht was er welchen kanal zuordnen muss

[NuclearPhoenix]

Guck ich mir alles mal an!

Inzwischen bin ich hierauf gestoßen:
Gamma-MCA

Ich habe mich dann man hingesetzt und das Einlesen der Werte für den nanoSpec modifiziert.

Sieht das hier irgendwie sinnvoll aus?

Sie dürfen in diesem Board keine Dateianhänge sehen.

Das sieht mMn auch nicht richtig aus. Welche Datei hast du denn dafür verwendet? Dann schau ich mir gerne mal an, ob es was mit dem Import oder der Datei selber zu tun hat.

[marvin]

Das sieht mMn auch nicht richtig aus. Welche Datei hast du denn dafür verwendet? Dann schau ich mir gerne mal an, ob es was mit dem Import oder der Datei selber zu tun hat.

Ich muss mir das decode nochmal genau ansehen, vielleicht schiebe ich die bits und bytes falsch. Es kann natürlich auch sein dass am MCA noch was nicht richtig eingestellt ist. Oder der Detektor (Scionix 76 B 76 /3) nicht mehr ok ist.

Ich habe keine Datei importiert, sondern die Verarbeitung der Daten über die serielle Schnittstelle angepasst. Der nanoSpec übermittelt die Daten in zwei bytes, die man zusammenbasteln muss...

[NuclearPhoenix]

Ich habe keine Datei importiert, sondern die Verarbeitung der Daten über die serielle Schnittstelle angepasst. Der nanoSpec übermittelt die Daten in zwei bytes, die man zusammenbasteln muss...

Achso ups, habe ich falsch verstanden. Wie formattierst du die Daten denn? Das ist das wichtigste, alles andere klappt dann "einfach so".

[marvin]

stell ich mich grad an oder putty streikt
ich clicke doch  links auf serial ,zb com4 ,19200,8, 1, none, xon/xoff und DTR Kabel Pin4 auf DTR

weder noch. Meine Information Ursprünglich war falsch. bzw hab ich die Pinbelegung aus dem Handbuch mißverstanden.

mit "to DTR" war DTR am PC gemeint, nicht am nanoSpec selbst...

Putty macht beim Öffnen der seriellen Schnittstelle DTR direkt an. Wenn man ein einfaches DB9 verlängerungskabel nimmt, ist der nanospec dann direkt im RESET. (Ich hab mir einen zwischenstecker gebaut, der die Verbindung zu pin 4 unterbricht.

Probier mal folgendes:
- Serielles Kabel abziehen
- putty mit 19200 8N1 / ohne handshake anschalten
- nanoSpec einschalten
- kabel aufstecken
- Return drücken

dann sollte die Bootloader meldung kommen.

Wenn das Programmieren der Firmware geklappt hat, sollte der nanoSpec nach dem Abziehen des seriellen kabels ein "lauflicht" mit den drei waagerechten segmenten der 7-segment anzeige machen, und dann irgendwann nur noch mit einem der senkrechten segmente blinken.

Programmieren mit
W 58
dann L
dann copy/paste aus der ".hex" datei.

[marvin]

Achso ups, habe ich falsch verstanden. Wie formattierst du die Daten denn? Das ist das wichtigste, alles andere klappt dann "einfach so".

Die Daten kommen wie folgt:
low byte  = 10LLLLLL
high byte = 11xHHHHH

bit 7 markiert "Event Daten"
bit 6 low/high byte
bit 5 beim high byte = 1 sagt, dass events verloren gegangen sind (dazu am bsten im Handbuch lesen )

Verarbeitung: (pseudocode)

  wenn rx > 127
    wenn rx AND 0b01000000 = 0 // low byte
      event = rx AND 0b00111111
    sonst   // high byte
      event = event OR (rx << 6)
  sonst
     "konsole daten"

also im prinzip keine hexerei, high/low unterscheiden, maskieren, rüberschieben


Edit: aaaah.. ich hab jetzt erst "gemerkt" wer du bist

Wenn ich zuhause bin kopiere mel meinen Code hierher...

ich hab im prinzip erstmal quick&dirty eine "addRawNanoSpec" routine gebaut, und rufe die in readUntilClosed auf.

alles < 127 schreibe ich in rawConsoleData, und die Events direkt per this.bufferPulseData.push(event) in die spectrum daten...

[NuclearPhoenix]

Und der Ausgang zur Konsole, wie werden die Daten dort ausgegeben?

[marvin]

Und der Ausgang zur Konsole, wie werden die Daten dort ausgegeben?

Ich schreibe die daten da nur rein. Beim nanoSpec kann man die Konsole während der Übertragung der Messdaten verwenden.

Wie gesagt, das ist bisher alles quick&dirty, aber das decoding sieht eigentlich gut aus.

Wenn man das mit dem nanoSpec ernsthaft integrieren will, muss man das handlich der Konsole anders machen, und start/stop Record am besten über die nanoSpec Kommandos regeln.

Ich muss mir jetzt erstmal noch die Konfiguration des nanoSpec ansehen, und irgendeine Quelle besorgen, damit man was sehen kann. Ich weiss eben auch nicht ob der PMT noch in Ordnung ist.

[NuclearPhoenix]

Ich frag das nur, weil man nach jedem event immer einen Strichpunkt (standardmäßig) hinzufügen muss, falls du das nicht schon machst. Sonst weiß die Software nicht wo eine Nummer aufhört und eine andere beginnt, da kommt dann irgendein Blödsinn raus.

[marvin]

Ich frag das nur, weil man nach jedem event immer einen Strichpunkt (standardmäßig) hinzufügen muss, falls du das nicht schon machst. Sonst weiß die Software nicht wo eine Nummer aufhört und eine andere beginnt, da kommt dann irgendein Blödsinn raus.

Für die Event Daten muss kein String geparsed werden. Ich sammle die beide bytes ein, rechne sie zusammen und schiebe den Wert direkt in "bufferPulseData"...

Code Auswählen Erweitern

  /*
    Decode nanoSpec event data

    nanoSpec eventData consists of two bytes that encode 11 bit
    event data:

    bit 7      marks the incoming char as event data
    bit 6      marks high or low event data (0 - low / 1 - high)
    bit 5      on the high byte marks an overflow of the "true event counter",
               if this is high, events might be missing in the cumulated event data
    bit 5 - 0  in the  low event data are bit  5 - 0 in the event data
    bis 4 - 0  in the high event data are bit 10 - 6 in the event data

    So, following operations decode two characters from the serial input
    to one event data word:

            10EEEEEE        rxByte 1 (low)
    0000000010EEEEEE        in 1
    0000000000111111        (and)
    0000000000EEEEEE        ev

                  11xHHHHH  rxByte 2 (high)
          0000000011xHHHHH  in 2
          0000000000011111  (and)
          00000HHHHH000000  (shl 6)
          00000HHHHHEEEEEE   ev
*/
  private addRawNanoSpec(uint8Array: Uint8Array): void {

    if (SerialManager.orderType === 'chron') { // CHRONOLOGICAL EVENTS
      for (const rxByte of uint8Array) {
        let rxNum:number = rxByte;
       
        if (rxByte > 127) {           // Event Data

          if ((rxNum & 0x40) == 0) {  // low data
            this.eventData = rxNum & 0x3F
          } else {                    // high data
            this.eventData = this.eventData | ((rxNum & 0x1F) << 6)
            if (this.eventData < 0 || this.eventData > SerialManager.adcChannels)
              continue; // Fixed value range. !FIX SERIAL COMMUNICATION ERRORS!
           
            if (this.bufferPulseData.length > SerialManager.maxSize) { // Protect from overflow and crashes
              console.warn('Warning: Serial buffer is saturating!');
              return;
            }

            this.bufferPulseData.push(this.eventData);
           
          }
        } else {  // Console Data
          if (this.rawConsoleData.length > this.consoleMemoryTotal - 1) {
            //console.warn('Serial console log is out of memory, deleting old history...');
            this.rawConsoleData = '';
          }
          this.rawConsoleData += String.fromCharCode(rxByte);
        }
      }
    } else if (SerialManager.orderType === 'hist') { // HISTOGRAM DATA
      // Kommt noch...
    }
  }


[marvin]

sieht das so besser aus?

Sie dürfen in diesem Board keine Dateianhänge sehen.

[wrdmstr inc.]

jein, es sieht so aus als wäre das ein ausschnitt vom spektrum und zwar da wo jetzt 500kev stehen, müsste ungefähr der 80kev "peak" liegen und das ganze mehr gestaucht, und iwo weiter rechts ist auch kein peak zu sehen der vom K40 bei 1462kev liegen müsste (in jeder Wohnung nach paar Minuten sichtbar wegen dem Zement) so ie hier: https://www.geigerzaehlerforum.de/index.php/topic,2071.0.html