Jump to content

Joey P

QRC Senior Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


Joey P last won the day on January 23 2018

Joey P had the most liked content!

Community Reputation

266 Excellent


About Joey P

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Joey P

    Context specify packet size

    I see that the file is missing the extension data packet, this is required. This shares the 4000 byte chunk with the context and goes first. The proper format can be found in the WBT File Format Documentation, as part of the WBT API documentation.
  2. There is little to no actual performance difference, when you do it dynamically you have to keep track of when things exist / nullness / lifecycle / etc. With that being said, unless you are using the class for callbacks, there is no good reason to not just spawn a WbtSystem wherever and whenever you need one on the stiack. The communications between the API classes and the daemon are instantiated in a behind the scenes singleton, so all of the really heavy lifing only happens the first time. However, if you are using callbacks with Qt please be advised that the callbacks happen on a separate thread, and should not interact directly with *any* QObjects, this is not safe. (http://doc.qt.io/qt-4.8/threads-qobject.html#signals-and-slots-across-threads)
  3. Joey P

    Context specify packet size

    File IO can be achieved by: Opening up a read iterator Iterating until you encounter context. Writing that context to a file Continuing to iterate through the stream, writing each 4000 byte context to the file and every 33 * 4000 byte data segment to the same file To answer your second question, currently packet sizes are fixed per QVRT specification to ensure quick reading / parsing operations.
  4. Joey P

    Tutorial section needed

    This is a good idea, we’re happy to provide a user community where tutorial type content beyond that which is included in the development kit by QRC can be easily posted or shared with others. This is part of our goal for this forum system, which is still building user base as the WBT becomes adopted by more and more groups. A way to do this with what we have, would be to post whatever content you (or others) may think valuable to share in the discussion area of each product. For example, in the WBT the discussion area is here: http://forum.qrctech.com/forum/22-wbt-discussion/. This was what we had envisioned as a way for users to talk with out users in a Non-QA format, what do you think of using that. We’d certainly welcome any content you’d like to add to enrich that area and help your fellow WBT users.. Beyond that, if there’s specific tutorial items you’d suggest QRC create, we’d welcome your thoughts and get someone assigned to creating them as quickly as we’re able. -Admin
  5. Joey P

    WbtAPI for directly streaming

    Can you be more specific on how to prefill the write iterator with data? You can prefill the write iterator's circular buffer by putting the desired data into each buffer chunk of the iterator and calling next, repeating the process for each buffer that was allocated by the creation of the iterator. The API docs really help here: A QVRT data stream is a packetized QVRT data stream that carries raw IQ data as well as other pertinent metadata establishing context (center frequency, sample rate, endpoints, etc). This stream uses a chunked circular buffer implementation to safely allow one writer and multiple readers. Each chunk of this buffer is divided into two areas: The IF Data Packet area- which contains 33 consecutive IF Data packets (each 4000 bytes) and the Context area- which contains a 4000 byte block containing context data (consisting of one Extension Data + one IF Context Packet). The WbtVRTWriteIterator operates by traversing the QVRT data stream buffer one buffered chunk at a time. The created stream can have multiple readers connected to it. This can be accomplished by either specifying this stream's WbtCommon::Streams::StreamInformationBlock in the constructor for WbtApi::WbtVRTReadIterator or moving an exiting reader to it usingWbtApi::WbtSystem::MoveReaderToNewStream method. Specification of all data and context packets used within a QVRT stream can be found within the WBT File Format document. So in short: 1. getCurrentLocationToWriteContext () and write your context information there, per the QVRT format documentation (you don't need to do this every time, just the first time, and any time your data would change) 2. getCurrentLocationToWriteData () and write 33 data packets at a time, per the QVRT format documentation 3. setContextAvailable() - If you performed step 1 4. ++ operator - to advance the buffer. Do this for the number of buffer chunks that you had set up in the bufferSize parameter of the write iterator 5. move the streams to the iterator 6. setStreamStarted () Do i only need to create a new WbtSystem obj and call startPlayback on it? Beforehand, you also need to get the information about the file you want to play, to set up the sample rate and center frequency. This can be accomplished using the following methods in WbtSystem. getRecordingInfo updateTunerSettings
  6. Sorry, misunderstood. If you do have a GRC gui component, it counts and should work. Have you tried the tutorial example? How the tutorial behaves should shed some light into the issue.
  7. As of this time, there is no proper way to have an app without a GUI component, due to how the signaling and API works at this time. At the very least, there needs to be an "about screen" with an icon.
  8. Joey P

    WbtAPI for directly streaming

    There is a way, however, it is fairly roundabout so we are actively working to improve this functionality. Expect to see something a lot more convenient within the next quarter. The current process is, 1. Create a WbtVRTWriteIterator, this will give you a handle to a new and empty shared buffer. 2. Prefill the write iterator with data, using the WBT File Format as a guide. (IF Data packets go into the main buffer area and context / extension data pairs go into the 4000 byte context section.) 3. Start a file that has the same radio configuration parameters (enabled tuners, span, bandwidth and center frequency) of what is intended to be streamed. This can be accomplished using WbtApi::WbtSystem::startPlayback. 4.Use WbtApi::WbtSystem::getActiveStreams to enumerate the active stream buffers on the system, that should include the file being played as well as the new stream created using the WbtVRTWriteIterator. 5. Use the function, WbtApi::WbtSystem::MoveAllReadersToNewStream to redirect all of the listeners from the old stream (including the radio, as well as any other listening apps) to the new one. Now, all data that has been written, or is being written to your write iterator will be streamed to the radio.
  9. Add the following line to your main.cpp. MainWindow w; w.move(-2000,-2000); w.show(); This will ensure that the window is moved outside of the screen area before it is captured by the app framework.
  10. Joey P

    QVRT Context packet Metadata Timestamp

    With combined tuners, this is usually the case, however, you can have situations where you have two separate streams of two separate sample rates interleaved in one file. In these situations, you would not be able to rely on this assumption. For the combined case, your example would indeed work. But not for all configurations that use Radio_AB as a radio selection.
  11. Joey P

    Wbtclient broadcast messages

    As of now, that is the only notification sent to users about actions performed within the GUI. There are no notifications for green arrow buttons. As for determining when tuner parameters (CF, bandwidth, etc) change, settings changed callbacks within the WbtSystem class can be used.
  12. Joey P

    QVRT Context packet Metadata Timestamp

    Thank you for the additional information. We're looking into the issue and will reply with additional information soon.
  13. Joey P

    QVRT Context packet Metadata Timestamp

    I would say that this is indeed not the expected behavior. Does this happen consistently, or just with some files? The things that come to mind that could cause this are: 1. Loss of GPS sync 2. Issues traversing file with file read iterator. Two things that would help us get to the bottom of this would be either: a) a source code snippet b) versions of software where file is captured and version of API used
  14. Joey P

    High Sample Rate Tuner Bandwidths

    Understood. Let us know if there is anything else we can do to help!
  15. Joey P

    High Sample Rate Tuner Bandwidths

    Apps should not experience any issues going into the future as a result of using these values. Because we do not allow bandwidths that are larger than the sample rate (for data integrity reasons), you can always be assured that the min and max values will be safe. I would feel free to use it and not worry about getting (or the possibility of) out of range values.