Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 4 FirstFirst ... 2 3 4
Results 76 to 83 of 83

Thread: Teensy with 4 or 5 wireless temperature sensors

  1. #76
    Senior Member CorBee's Avatar
    Join Date
    Jun 2018
    Location
    Netherlands
    Posts
    339
    This thread points to the same kind of issue : https://forum.pjrc.com/threads/46757...age-is-correct

    So its a matter of defining the variables on both arduino and teensy side properly and unambiguous.
    Code:
    const uint16_t ID=1;
    typedef struct {
    uint16_t NodeId; //2 byte integer
    float temperature; //4byte float
    
    } PayloadFrame;
    static PayloadFrame Out_Payload; //the variable used in sending data
    
    Out_Payload.NodeId=ID;
    Out_Payload.temperature=temperature;
    radio.write( &Out_Payload, sizeof(Out_Payload) )
    The float on teensy is default 32 bit it seems and the endian coding is the same as in arduino (LSB). So its my guess that this is the only change needed.
    Last edited by CorBee; 09-29-2020 at 05:28 AM.

  2. #77
    Senior Member
    Join Date
    Jun 2015
    Posts
    285
    Quote Originally Posted by CorBee View Post
    Hi,

    You cant have 8 digits in an unsigned int normally ... so something must have gone wrong in the code either when sending or reading.

    Cor
    PS just checked. The unsigned int should be 2 bytes and the float is 4 bytes on an arduino, so in total 6 bytes. But ... if you are receiving with a NON-arduino but a teensy you will need to make the type-definition of the structure more strictly.
    Sorry been off line for a few days.
    Thanls for that info.
    Nothing is ever simple is it

  3. #78
    Senior Member
    Join Date
    Jun 2015
    Posts
    285
    Will give the 'type-definition' stuff another crack in the morning.

    On a side note in the mean time...
    As a stop gap, I did what I refered to in a previous post -ie added 2000 to the reading of 1 sensor before TX'ing & 3000 to the other.
    The idea being that I would know where the reading came from.

    It worked fairly well but not as good as I'd.
    So I editted my Rx sketch to only use 1 pipe for Reading ( at 1 point I had 3 running for 3 different remote sensors) to see if I could improve the Rx'ing of 1 sensor.

    Code:
    radio.openReadingPipe(1, addresses[1]);
    //radio.openReadingPipe(2, addresses[2]);
    //radio.openReadingPipe(3, addresses[3]);
    radio.startListening();
    I left all 3 TX'ers running though. (Note each has a unique Pipe address set for writting.
    Weirdly though, I was still able to pick up readings of in the 2000 & 3000 range with the modified code.

    Should that even be possible with only 1 pipe open for reading.

  4. #79
    Senior Member
    Join Date
    Jun 2015
    Posts
    285
    Was just starting to believe it was time to give up on the 'typedef struct' stuff.

    Just couldn't get it to work fully.

    Code:
    typedef struct {
    uint16_t NodeId; //2 byte integer
    float temperature; //4byte float
    
    } PayloadFrame;
    
    static PayloadFrame Out_Payload;
    Implemented as suggested - but the recieved payload data only ever returned 1 of these 3 pairs of values: 0 & 0.00, 4 & 0.00, 32768 & 0.00
    with
    Code:
    const uint16_t ID=4;
    .
    Ie never a valid temp reading for the float.
    But occasionaly a valid for the ID.

    No idea why - but I decided to add a 3rd piece of data to the payload structure.
    It was a 2nd uint16_t sending its value as ID+ID

    With this I now get either :
    4,8, correct Temp reading
    or
    32768, 16792, 0.00
    or
    0, 16792, 0.00

  5. #80
    Senior Member
    Join Date
    Jun 2015
    Posts
    285
    TBH.
    I apprecaite folks are not recommending using my earlier stated method of adding order of a 1000 to the various senors to ID them.
    But that does appear to work.

    So wondering what I will actually benefit from perserving with the 'typedef struct'.

  6. #81
    Senior Member CorBee's Avatar
    Join Date
    Jun 2018
    Location
    Netherlands
    Posts
    339
    Hi,

    I cant answer that for you. But encoding data with the ID of a sensor is only going to work for a few sensors and a single dataset. If you ever plan to extend that becomes more and more difficult. But its your project !

    Cor

  7. #82
    Senior Member
    Join Date
    Jul 2020
    Posts
    174
    It sounds like either the data is not being copied into the struct, or the struct is different between the sender and the receiver.

    When you ask the compiler to set aside some memory for a struct, that memory doesn't get blanked, so it will just be whatever random noise or previously-used data was there before.

    32768 is a very curious value to just show up at random (in binary it's 1 followed by a bunch of 0s), a number that just happens to be extremely round for no apparent reason. That tells me something isn't aligned, like maybe you have a variable as int16_t in one place and uint16_t in another. Or, the memory location was previously used for something else, and data wasn't copied into it.

    If you create this struct and stuff it with hard-coded test values (like ID=2, temp=15) rather than reading sensors or anything like that, can you receive it and get the same values out?

  8. #83
    Senior Member CorBee's Avatar
    Join Date
    Jun 2018
    Location
    Netherlands
    Posts
    339
    Hi,

    I sometimes have used the following code, where the pragma pack(1) forces the compiler into keeping the structure byte aligned

    Code:
    #pragma pack(1)
    typedef struct newPayload {
    	//8 bytes 
    	uint8_t msgFormat; //#00
    	uint8_t msgNodeId; //#01
    	uint8_t msgType; //#02
    	uint16_t data0; //#0304
    	uint16_t data1; //#0506
    	uint8_t checkId; //#07
    } newPayload;
    #pragma pack()
    This is a message system for part of my setup, it sends both at the beginning and at the end of the structure the ID of the sensor. This allows easy/fast checking of the data as the beginning/ending byte need to be the same for a proper received message.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •