PanStamp Board RGB,CW,WW;DMX;IR

[ext23]

Da meine alt AVR panStamps langsam zur Neige gehen, habe ich jetzt versucht ein AVR 2 zu flashen. Das klappt auch, aber irgendwie bekomme ich die alt berühmte Meldung "value has to be 10 byte(s) in size". Device löschen hat nichts gebracht. EEPROM löschen (if 0 etc. entfernen und sketch einmal ausführen) hat auch keine Besserung gebracht. Was habe ich denn nun schon wieder falsch gemacht?

Btw. läuft der Sketch schon mit der neuen SWAP Lib und der neuen Android IDE? Hatte das schon jemand portiert?

UPDATE:
Kurze Frage:

Code Auswählen Erweitern

unsigned int interval = swap.txInterval[0] << 8 | swap.txInterval[1];
Fehler: sketch:512: error: invalid types 'uint16_t {aka unsigned int}[int]' for array subscript
Jemand eine Idee? er erwartet also unit16, und bei uint benutzt der aber 32 oder wie? dachte das ist long ?!?
(Ich versuche gerade mal den Sketch zu kompilieren unter der neuen Android IDE und neuem SWAP und dieser einer Fehler ist noch über )

/Daniel

[ext23]

Hallo,

neues Problem, auch auf den Verdacht hin das keine Antwort kommt aber ich versuch es mal

Ich hab ein funktionierendes hex auf ein anderen panstamp geflashed, wird auch erkannt, mit Adresse 5, habe die auf 11 geändert. Aber auch nach einem Status request und XML read fehlen die entsprechenden Set Befehle. Hier mal ein Listing:

Code Auswählen Erweitern

Internals:
   DEF        11
   Developer  justme
   IODev      PanStick
   LASTInputDev PanStick
   MSGCNT     434
   NAME       SWAP_05
   NR         2014
   PanStick_LQI 44
   PanStick_MSGCNT 434
   PanStick_RAWMSG (FE2C)0011001B00110D00000015
   PanStick_RSSI -75
   PanStick_TIME 2016-07-15 14:19:36
   Product    RGB driver board with IR
   STATE      FFFFFF00
   SWAP_00-ProductCode 0000002200000003
   SWAP_00.1-ManufacturerID 00000022
   SWAP_00.2-ProductID 00000003
   SWAP_01-HardwareVersion 00100036
   SWAP_02-FirmwareVersion 00020003
   SWAP_03-SystemState 01
   SWAP_04-FrequencyChannel 00
   SWAP_05-SecurityOption 00
   SWAP_06-SecurityPassword 00
   SWAP_07-SecurityNonce 0D
   SWAP_08-NetworkID B547
   SWAP_09-DeviceAddress 11
   SWAP_0A-PeriodicTxInterval 003C
   SWAP_MISSED 0
   SWAP_Sent_unconfirmed 1 Sent_unconfirmed
   SWAP_lastRcv 2016-07-15 14:19:36
   SWAP_lastSend 2016-07-15 14:19:00
   SWAP_nonce 1B
   TYPE       SWAP
   addr       11
   devices
   nonce      1
   Readings:
     2016-07-15 14:19:36   0B-RGBlevel     FFFFFF
     2016-07-15 14:19:36   0B.1-Red        FF
     2016-07-15 14:19:36   0B.2-Green      FF
     2016-07-15 14:19:36   0B.3-Blue       FF
     2016-07-14 21:50:09   0B.4-White      00
     2016-07-15 14:19:01   0C-IRCommand    0000000000
     2016-07-15 14:19:01   0C.1-Type       00
     2016-07-15 14:19:01   0C.2-Value      00000000
     2016-07-15 14:19:36   0D-InternalTemperature 00000015
     2016-07-15 14:19:01   0E-PowerOnState 3AFFFFFFFF
     2016-07-15 14:19:01   0E.1-State      3A
     2016-07-15 14:19:01   0E.2-Brightness FF
     2016-07-15 14:19:01   0E.3-Color      FFFFFF
     2016-07-15 14:19:01   0F-Command      00000000000000000000
     2016-07-15 14:19:01   0F.1-Cmd        00
     2016-07-15 14:19:01   0F.2-Args       000000000000000000
     2016-07-15 14:19:01   12-DMX_Base     01
     2016-07-15 14:19:01   13-LedPower     0194
     2016-07-15 14:19:36   internaltemperature 21
     2016-07-15 14:19:36   state           FFFFFF00
   Product:
     label      RGB driver board with IR
     name       rgbdriver
     pwrdownmode 0
     Registers:
       11:
         HASH(0x5f9b120)
         HASH(0x5f9b4e0)
         HASH(0x5f9a9c0)
       12:
         hwmask     02
         name       IRrecv
         swversion
         type       regular
         endpoints:
           HASH(0x5f9bcd8)
           HASH(0x5f9a978)
           HASH(0x5f9bab0)
       13:
         hwmask
         name       Temp
         swversion
         type       regular
         endpoints:
           HASH(0x5f9d338)
       14:
         hwmask
         name       PowerOn
         swversion
         type       config
         endpoints:
           HASH(0x5f98d90)
           HASH(0x5f96b00)
           HASH(0x5f96fe0)
           HASH(0x5f96f80)
       15:
         HASH(0x5f9d938)
         HASH(0x5f9d080)
       16:
         hwmask     08
         name       Repeater mode
         swversion
         type       config
         endpoints:
           HASH(0x5f9a738)
       17:
         hwmask     01
         name       Bri
         swversion
         type       regular
         endpoints:
           HASH(0x5f9cfd8)
       18:
         hwmask     04
         name       DMX
         swversion  00020001
         type       config
         endpoints:
           HASH(0x5f99018)
       19:
         hwmask     10
         name       LedPower
         swversion
         type       regular
         endpoints:
           HASH(0x5f9a090)
       20:
         hwmask     20
         name       IRsend
         swversion
         type       regular
         endpoints:
           HASH(0x5f9d1e8)
           HASH(0x5f9cf48)
           HASH(0x5f9ba50)
           HASH(0x5f9d458)
   sentList:
     ARRAY(0xa9ed178)
Attributes:
   IODev      PanStick
   ProductCode 0000002200000003
   room       X_Autocreate
   userReadings internaltemperature:0D-InternalTemperature.* {hex(ReadingsVal($name,"0D-InternalTemperature","0"))}

[ext23]

Moin,

der Alleinunterhalter muss mal wieder was loswerden. Sagt mal wenn ich der panstamp Fuse-Bit Doku im Wiki so glauben kann, ist die Brown-out Detection ja deaktiviert. Das würde erklären, dass ein Kollege massive Probleme hat, wenn er sein Board vom Strom trennt. Da vergisst es nämlich häufig einige Sachen so das man erst ein eeprom clear ausführen muss. Hat jemand eine ähnliche Erfahrung gemacht?

/Daniel

[justme1968]

ja und nein.

die doku im wiki ist zumindest in der version die ich kenne mit vorsicht zu geniessen weil komplett falsch. die werte haben zu einem unbenutzbaren panstamp geführt weil sie die falsche takt quelle aktiviert haben.

zur brown out geschichte gibt es aber im panstamp forum etwas. ich erinnere mich nur nicht mehr genau was es war.

ich habe einen panstamp der manchmal genau einen eeprom wert (den fürs transmitt intervall) 'vergisst' wenn man ihn vom netz trennt. ich habe das aber bis jetzt nicht weiter verfolgt. alle anderen arbeiten problemlos.

gruss
  andre

[ext23]

Aha, dann lese ich da nochmal nach. Ich hab die Fuse Bits mal ausgelesen, stimmen soweit wie im Wiki und Brown out detection ist wirklich aus.

Ich habe jetzt die Antennen getauscht und schwups laufen die panstamps besser, irgendwie sind die kurzen Antennen Asche.

Aber einen habe ich noch der einfach nicht die Hardware und Firmware Version mit übermittelt, daher kommt dann auch der Fehler mit dem 10 Byte. Keine Ahnung wo da das Problem ist, ich bin noch am Forschen.

/Daniel

[joshi04]

Könntest Du bei Gelegenheit vielleicht die Geschichte mit den Antennen noch einmal detaillieren? Ich meine, von welchen "kurzen Antennen" sprichst Du? Sind das die, die auch bei panStamp geordert werden konnten (siehe Foto)?

Bzw. mit welchen Antenne laufen bei Dir nun besser?

Bei mir läuft zwar soweit alles, aber Potential gibts ja immer.

Schöne Grüße,
John

[ext23]

Genau, das sind die die bei mir einigermaßen funktionieren. Es gibt aber noch die:

http://panstamp.com/store/index.php?id_product=20&controller=product

Komischerweise auch als Lambda/4, ich würde zu gerne mal eine auseinandernehmen weil bei Lambda/4 muss der Draht ja 8,46 cm lang sein. Die Antennen sind bei mir aber so schlecht, das ich der Meinung bin das sind keine 868 MHz Antennen, da stimmt was nicht.

/Daniel

[joshi04]

Danke für die schnelle Antwort.

Ja, die sieht tatsächlich deutlich kürzer aus, als die mit Gelenk.

Dann drücke ich die Daumen für den einen verbleibenden, der nicht so richtig will.

Schöne Grüße,
John

Edith: Und wer lesen kann, ist klar im Vorteil...

[ext23]

Japp, der überträgt ums verrecken nicht die Firmware und Hardware Version, das ist vermutlich auch der Grund warum immer die 10 Byte Meldung kommt. ich weiß aber nicht wann er die Daten übermittelt, ob nur beim ersten Anmelden oder auch bei einem status querry, der bleibt nämlich immer bei 1 unconfirmed stehen. Es kann natürlich an meiner build Umgebung liegen, aber mhh etwas komisch finde ich das schon. Das kann ja nun kein Hexenwerk sein das Projekt sauber zu kompilieren und ich habe zumindest nicht mal Warnings also sollte das passen.

/Daniel

[joshi04]

mM sollte er es übertragen, wenn:
- Er das erste mal mit Strom versorgt wird.
- Man den Reset-Button drückt. (Nach meinem Verständnis müsste das einen Neustart des panStamps auslösen.)
- Man die Daten per statusRequest abfragt und er diese als Antwort zurück liefert.

Letzteres geht natürlich nur, wenn dieser Request ihn auch erreicht. Wenn bei Dir also 1 unconfirmed steht, wäre das zumindest ein Hinweis, dass ihn nicht alles erreicht hat. Ein statusRequest braucht mM 21 Msg, zumindest steht das bei mir, wenn einer mal nicht erreichbar ist, weil gerade aus und ich das trotzdem versucht habe.

Ich habe aber auch die Erfahrung gemacht, sobald da mal der Wurm in den vorliegenden Daten drin ist (Daten nicht komplett), ist es mir nur einmal gelungen, die Daten per statusRequest zu "holen".

Alles oben genannte sind aber nur Erfahrungswerte. Ich habe nicht in die Firmware geschaut, was er tatsächlich machen sollte.

Schöne Grüße,
John

[ext23]

Genau bei 22 fängt der bei mir an glaube. Mhh das würde ja bedeuten das doch was mit meinem Build nicht stimmt. Mhh ach diese ganze Arduino kacke ist doch scheiße. Mit AVR Studio hatte ich solche Probleme nie ohne diese ganzen Arduino libs.

/Daniel

[ext23]

Jetzt hat er es, nach gefühlten 20 mal Reset drücken 40 cm neben dem Modem PanStick. Also das Protokoll ist doch irgendwie Grütze

So sehr schön, dann kann ich ja jetzt mal meine Versuche starten das ganze mit der neuen SWAP Lib bzw. der aktuellen Arduino IDE zum laufen zu bringen.

/Daniel

[joshi04]

Sag mal, unter welcher Umgebung und unter welchem OS kompilierst Du eigentlich? Von der Struktur des gepackten Sketches her und ich bin der Meinung, Andre hätte das mal erwähnt, hat er immer mit ino unter eine Linux-Distr. kompiliert.
Ich hatte das im Wiki mal versucht für die alten Versionen, nachvollziehbar zu dokumentieren.

Ich habe den Verdacht, dass abhängig von der Umgebung immer ein bisschen was anderes herauskommt. Allerdings bin ich dem nie genauer nachgegangen z.B. über Hashes.

Eigentlich wundert mich, dass nicht noch viel mehr Leute Probleme melden oder ich mache irgendwie grundsätzlich was falsch... Andererseits wird das RGB-Modul laut Statistik nur 18 Mal verwendet.

Wenn ich Wünsche nennen dürfte, wäre auf alle Fälle wichtig, sich von allen "Bausteinen" die Versionen oder Quellen zu notieren, sonst kann man das später nicht nachvollziehen.

Schöne Grüße,
John

[ext23]

Also ich mach das wie Andre unter Linux mit den Android Kit. Alles aber eben in der alten Version.

Aber jetzt mach ich es mal unter Windows mit der Android IDE (die wirklich grottig ist) und so. Aber wie gesagt der Code lässt sich nicht kompillieren. Man muss an ein paar Stellen die Funktionen umbenennen aber es gibt noch einige Stellen wo ich nicht weiter komme, da wird irgend was falsch gecasted oder so, ka.

Gruß
Daniel

[DJAlex]

Hi,

hab ja ne ganze Weile nix mehr hören lassen deshalb jetzt ein StausUpdate. Die sache mit den Hexfiles hab ich leider nicht auf die Reihe gebracht, hab nix gefunden womit ich das mit Mac gscheid raufladen kann. Dafür hab ich einen anderen Weg gefunden das Problem mit den "value has to be 10 byte(s) in size.." zu lösen. Ich alle 4 Stunden einen reload der 35_SWAP_0000002200000003.pm. Seid dem ist das Problem eigentlich weg und alles läuft zuverlässig. Was mir noch aufgefallen ist. Das Wifilight Modul hat die Möglichkeit ein ColorCast Attribut zu setzen um die genaue Farbmischung einzustellen. Das wäre noch eine Feine Sache wenn sich sowas einbauen lässt. Oder kann ich das irgendwie anders hinbasteln?

Grüße

Alex