GQ Electronics Technical Support Forum

GQ Electronics Technical Support Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ
Save Password
Forgot your Password?

 All Forums
 GQ Electronics Forums
 3. GQ EMF EF Meter RF Spectrum Power Analyzer
 GQ-RFC1701 Protocol
 New Topic  Reply to Topic
 Printer Friendly
Author  Topic Next Topic  


2 Posts

Posted - 11/03/2018 :  18:05:50  Show Profile  Reply with Quote
Discussion on improving the GQ-RFC1701 Protocol, specifically as relates to EMF-380V2 in my case.
Have you guys considered open-sourcing your firmware? I would probably have just poked around in the code to try and fix these if it were available.
Added a couple things I had forgotten.
Edits to 'menu' issue below.


  • A method to retrieve the RF channels as relates to the RF data points from the device. The <GETBANDDATA>> command retrieves a variable-length array of data points and it must be currently inferred which frequency that each data point belongs to by getting the active frequency range and distributing that range across the length of the returned data array (which is likely not terribly accurate).

  • A table map of each option and corresponding index that is returned by the <GETCFG>> command. Currently, the only method to obtain this seems to be changing each individual option manually one-by-one and collecting the config array to see which option changed and what the new value is.

  • Selecting the frequency range using UI simulation is very cumbersome and requires many 'thread sleeps' to allow each command to process sufficiently. It would be great if there was a simple command to set the frequency outside of the UI. By iterating through the UI steps you lose a lot of time between samples (approximately 4 minutes) when trying to store a full spectrum sample (data points from every antenna at any given point in time).

  • There doesn't appear to be a bullet-proof method of detecting when a frequency sample has completed a full sweep. On the higher frequencies, it's pretty much real-time, as all the data points are filled by the time we get around to reading a sample. On the lower frequencies, it can take quite a long time to fill out the data point array initially (in the minutes time frame). The only method I've been able to identify is to iterate over the returned data points and wait for all of them to read greater than -107 dBm. This doesn't always work, however, because sometimes there are legitimately values of -107 dBm in a fully-populated array, so it tends to wait unnecessarily and sample more than it has to in order to ensure that we get a full sample. I wonder if one array element could be reserved for a 'sample complete' flag and we could scrutinize that one element. Or another command altogether to get the status of the sample - <GETSAMSTAT>> that would return 0 for incomplete or 1 for complete. Honestly don't care how it's implemented, but would like some sort of capability here.

Issues (Bugs):

  • Some frequency ranges get 'auto zoomed' after selection. This complicates the frequency selection, as you have to 'zoom out' after every frequency change to make sure you're getting the full range.

  • If you read the mode with the <GETMODE>> command while 'Zoomed in', it always returns the lowest frequency range rather than the selected range or even the visible range. This means you always have to zoom out before you can accurately read the current frequency range using the <GETMODE>> command. This further complicates the frequency iteration capabilities as discussed above. Not only do we have to painstakingly simulate each UI interaction to change the frequency, we also have to assume that the view is 'zoomed in' and account for that on each frequency change.

  • Occasionally, without notice, the 'power button menu' pops up on the device without the button being pressed or the button command being sent to the device. There doesn't seem to be a method to detect that we've even entered the menu, so it's difficult to work around this anomaly. This would be irrelevant if there were a programmatic method for selecting the frequency, however. If UI simulation was not required, the UI state would be irrelevant.

  • The lowest frequency range is reported differently by the protocol (153 - 279 kHz) than it is by the UI (150 - 531 kHz). (Obviously) they should match, but which one is actually correct?

Edited by - ismoody on 11/04/2018 06:13:15
Reply #1


301 Posts

Posted - 11/05/2018 :  16:51:38  Show Profile  Reply with Quote
Hi ismoody,

I'm currently checking your suggestions/feedback to see if we can implement them in our code.

Some comments/answers,
.We'll see if we can do this one. There's a lot of frequencies that were scanned so it needs to make sure which frequencies the
<GETBANDDATA>> data came from.
EEPOM_PowerOnOff, //to check if the power is turned on/off intended

. Just to make sure, you're not talking about the EMF PRO software?
. Ok we'll see, but after a sweep the band starts again, so you when would you set that flag back to zero?

. That was intentional because the full band is kind of slow, so we decided to zoom in at the middle to speed things up a little
. Yes that's just to determine which band you're at and not the specific range of frequency.
. Is this happening on the simulation? (Not EMF PRO)? and not on the device correct?
. The protocol wasn't updated so we should update it soon. The correct is 153 - 531 kHz from the device.

Thank you very much for your feedback!

Edited by - EmfDev on 11/05/2018 16:52:39
Go to Top of Page
Reply #2


2 Posts

Posted - 11/07/2018 :  06:10:27  Show Profile  Reply with Quote
For this entire post, I'm speaking specifically about the protocol and interactions with the firmware, not your software implementation.
I should have numbered the bullets.
The fourth 'enhancement' bullet: my main issue here is that I don't want to read a blank array. Even though it rests the sweep, I just need to know if the array has been populated. To make it more broad, however you may consider resetting the flag after a successful call to getrfdata?
The first issue bullet: That makes sense, but could this be optional rather than 'forced'?
Second issue bullet: I wouldn't be concerned if it returned the 'visible frequency range', but the issue is that it returns the wrong frequency range. It should return the currently selected frequency range regardless of zoom level, correct?
Third issue bullet: this is happening on the device while connected via USB using the protocol. I found that it gets worse after the device has been running for a few days, but after yanking the battery and powering back on, it stops for a while.

Thanks for the dialog here, excited to see where we can go with this super useful, yet very reasonably priced product. Excellent work so far.
Go to Top of Page
Reply #3


301 Posts

Posted - 11/07/2018 :  11:56:28  Show Profile  Reply with Quote
So what we can do is set a flag and can return the correct frequency. But we will keep the zoomed in version.
Will update the protocol soon.

As for the button press, does it also happen when the USB is not connected? Maybe the screw is a little tight.
Thank you.

edit. Updated protocol will be uploaded soon. You can also ask support for new firmware update. Thanks!

Edited by - EmfDev on 11/08/2018 11:40:05
Go to Top of Page
   Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.09 sec. Snitz Forums 2000