[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[THREDDS #QGE-896632]: Nexrad Level 2 Support

Hi,

Thanks for letting us know. I figured it was something like that.

Ryan

> Hi Ryan,
> 
> Just wanted to reply to let you know I've worked this out. I've spent ages 
> trying to figure out that arbitrary number, but I now understand the logic. 
> The loop is assuming message sizes of 2432 length, but message 31 is 
> variable. On each loop, the message31Offset is being set to the excess length 
> after the standard 2432 bytes of a normal message. So on the first loop, to 
> get to the position in the array, the formula 1 x 2432 x 12 for the header is 
> correct.
> 
> If the next message type is 31 and therefore variable length, simply doing 2 
> x 2432 would give the correct position in the array for this message, but not 
> the next message, so the excess number of bytes in the message is calculated 
> by multiplying message size in halfwords by 2 and adding the header, before 
> removing 2432 to just calculate the number of bytes after the end of the 
> standard length of a message.
> 
> On the third message, 3 x 2432 works, but because message 2 was message type 
> 31 and therefore variable, adding on this additional number of offset bytes, 
> leaves you in the right place to read the next message.
> 
> All makes sense now!
> 
> Just wanted to email to share the insight, as you took the time to help me.


Ticket Details
===================
Ticket ID: QGE-896632
Department: Support THREDDS
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.