Clarification IMU timestamps

[jagra92]

Dear clarius team,

i am using the solum api to capture imu data from the sensor in real-time. However, to me it is not exactly clear how to interpret the imu timestamps. I simply print the timestamps of the imu sensors readings by activating the motion data and adding a few lines to the image callback in the swift example:

// New images calblack
solum.setNewProcessedImageCallback({ (imageData: Data, imageInfo: UnsafePointer<CusProcessedImageInfo>, npos: Int32, positions: UnsafePointer<CusPosInfo>) -> Void in
    // Converting the raw image data into a CGImage which can be displayed
    let nfo = imageInfo.pointee
    let rowBytes = nfo.width * nfo.bitsPerPixel / 8
    let totalBytes = Int(nfo.height * rowBytes)
    let rawBytes = UnsafeMutableRawPointer.allocate(byteCount: totalBytes, alignment: 1)
    let bmpInfo = CGImageAlphaInfo.premultipliedFirst.rawValue | CGBitmapInfo.byteOrder32Little.rawValue
    imageData.copyBytes(to: UnsafeMutableRawBufferPointer(start: rawBytes, count: totalBytes))
    guard let colorspace = CGColorSpace(name: CGColorSpace.sRGB) else {
        return
    }
    guard let ctxt = CGContext(data: rawBytes, width: Int(nfo.width), height: Int(nfo.height), bitsPerComponent: 8, bytesPerRow: Int(rowBytes), space: colorspace, bitmapInfo: bmpInfo) else {
        return
    }
    self.image = ctxt.makeImage()
    
    print("---")
    for i in 0..<npos {
        print(positions[Int(i)].tm)
    }
    
})

An exemplary output for five consecutive frames looks as follows:

---
689463280470
689505028270
689546733300
689558527870
---
689505028270
689546733300
689558527870
689578225650
---
689546733300
689558527870
689578225650
689619792810
---
689578225650
689619792810
689660822410
689672663550
---
689619792810
689660822410
689672663550
689692724910

So apparently, on average 4 imu sensor readings are associated with one image frame, which would correspond to approximately 100hz (which is at the lower end of the 100-200hz i would expect reading different other issues here on github). However, several readings have the same timestamp (and same imu data), e.g. 689546733300 in the first three frames. As the imu readings should be much faster than the ultrasound imaging, i assumed an unambiguous assignment. Could you clarify this issue or point me in the direction where i misunderstood the relationship between image frames and imu sensor data?

[julien-l]

B-images are generated by compounding several US frames together. Frames are stored in some sort of circular buffer so it is possible they are re-used when generating B-images in sequence, for example the frame 689546733300 is used to generate the first tree B-images.

[clariusk]

in the latest version, we tried optimizing the IMU capture where we don't obtain data when the device is acquiring images, this can result in a noise bias within the magnetometer data, hence the resulting sampling rate will seem lower. I'm not sure this is functioning the way I intended it to, so stay tuned for changes in the future to IMU capture.

For your comment on duplicate IMU stamps, it may be that the initial frames have a ramp up time where the data is not read again for some time, do you see duplicates past the first few frames as well?

[jagra92]

Thanks for your prompt replies. The duplicated IMU timestamps seem to be the result of the imaging mode. I loaded the MSK application and the SC mode was set as default. When switching to B mode a single IMU reading is assigned to each US frame (@julien-l that's what you meant, right? I guess single B images are not compounded or are they?). The low IMU sampling rate (same as the imaging framerate) is then probably a result of the optimised capture in the latest version. Thanks again for your help and keep up the great work.

[clariusk]

ok interesting, we can definitely investigate using compound with the IMU, not sure I've tested this, in theory new data should be acquired and not re-assigned, since frames are still captured sequentially.