GQ Electronics Technical Support Forum


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

 All Forums
 GQ Electronics Forums
 2.GQ Geiger Muller Counter
 32 byte limitation for setting wifi on GMC600
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

gmcuser

4 Posts

Posted - 08/12/2019 :  18:34:52  Show Profile  Reply with Quote
Is the limitation on sending more than 32 bytes part of the firmware, or is there another way to communicate with the GMC-600? Often I have wifi networks that have a longer sid or especially the wifi password. The current 32 byte limitation prevents the counter from working at all because the user cannot enter the full information either through the form in the GMC data viewer, or using the AT+CWJAP_CUR command. At least with the ESP8266, we know that it is capable of longer sid names and passwords, so is there anyway to program the ESP8266 directly, so that we can make the device useful on wifi networks?
Thanks!
Reply #1

EmfDev

800 Posts

Posted - 08/13/2019 :  09:19:52  Show Profile  Reply with Quote
Hi gmcuser, there are limitations on the WiFi only 32 bytes are accepted as of now but we will be working to change it to support more than 32 bytes of data.

As for the AT commands, I believe it can support up to about 256 bytes.
Go to Top of Page
Reply #2

gmcuser

4 Posts

Posted - 08/13/2019 :  19:17:42  Show Profile  Reply with Quote
Thanks. The problem with the AT commands is that the GQ Terminal App also limits those to 32Bytes.
For example if I type AT+CWJAP_CUR in the command text field, and "demosid, longwifipasswordmorethan32byteshere" in the parameter field, then you also get the 32byte error when you click Send command with Paramters.
If this is an artificial limit in the GQ Terminal app, then maybe you could remove that so we can set the WPA password for networks that have long ones. Thanks again.
Go to Top of Page
Reply #3

EmfDev

800 Posts

Posted - 08/14/2019 :  09:58:30  Show Profile  Reply with Quote
That's true. We will also consider updating the terminal. Also you can use other software you trust to send AT commands to the unit.
Go to Top of Page
Reply #4

gmcuser

4 Posts

Posted - 08/14/2019 :  15:26:39  Show Profile  Reply with Quote
Thanks. At least on windows 10, doing it from the GMC Data viewer might be better. When I try to open the COM port with putty or teraterm at 115200,8N1 it does connect but I am not able to send any commands to it, so there may be some issue on Windows 10 using terminal programs.
Go to Top of Page
Reply #5

gmcuser

4 Posts

Posted - 08/18/2019 :  18:45:06  Show Profile  Reply with Quote
There are a couple of issues regarding setting the wifi directly via the AT commands.
The first problem is just doing it, because the GMC DATA viewer doesn't allow sending more than 32Bytes even with AT commands.

When trying to use a terminal program, I ran into issues - I tried terraterm, putty, minicom, etc... I think something is happening with buffering maybe.
Every time I connected and did <GETVER>> nothing would happen.

I finally just used the python serial libraries to send what I needed, and was able to get GMC-600 to associate by sending it:

<AT+CWJAP_DEF="mysid","mysecurebutlongwifipasswordetc">>

The geiger counter shows up as ESP_A92193 with an IP, and the AT+CWJAP_DEF? shows it associated. Yeah!

However, your firmwire doesn't seem to know that. If I try to test the connection from the GMC-600 it will complain that Wifi is not on.
But when I try to turn it on with <WiFiON>> then my good values are overriden by the GMC settings for wifi, which of course doesn't like more than 32 bytes for some reason.

So I think I'm stuck unless there is a workaround or some firmware fix, beyond downgrading the security of my wifi network. The easy fix would just be to look at the value of the AT+CWJAP_DEF?, and use that if associated. And if not then do as current behavior.
Go to Top of Page
Reply #6

EmfDev

800 Posts

Posted - 08/19/2019 :  09:59:01  Show Profile  Reply with Quote
That's because the <WiFiON>> returns the variable that was when when setting the Wi-Fi ON from the device. Let us think about it maybe there's a workaround.
Go to Top of Page
  Previous Topic 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.12 sec. Snitz Forums 2000