There was a similar question before, maybe you can bump that one
Photon memory map - https://github.com/spark/docs/issues/82 - shows where to change the SSID prefix, but doesnât tell the format except itâs in softap.cpp. This must be FAQ and described somewhere but I couldnât find it. So, this is how to do it.
$ echo âMy Cool Prefix Hereâ | perl -ne âchop; printf("%c%s", length, $_)â > ssid_prefix
$ dfu-util -d 1d50:607f -a 1 -s 1826 -D ssid_prefix
Note that the maximum length of the prefix is 25, and you need to match [SparkSetupCustomization sharedInstance].networkNamePrefix as well.
If you change the SSID, the mobile apps and the particle CLI wonât find the device, which would seem to reduce the usefulness of SoftAP mode.
Please tell me more about your use case for making the SoftAP mode name configurable.
Cheers,
mat.
How do you figure that?
If a Photon ever should be used commercially I don´t think many companies would like to use the Particle app or Particle-CLI for claiming devices. That is why Particle have released the libraries for iOS development and so on.
We are developing a commercial product and of course want our product name as the SSID, we also have our own iOS client that will do the claiming.
//Henrik
Hi @henkep, that makes perfect sense, sorry wasnât thinking clearly, and thinking back to how things were for very early versions of the mobile SDK.
The format of the SSID in memory is
1-byte for the length of the SSID prefix
N-bytes for the SSID prefix.
This is something that weâll add to firmware so the SSID prefix can be set from code.
No worries.
Any ETA on when that firmware change can be in effect?
//Henrik
Any news wrt this matter? This is something that is critical for the application I am currently working on as well.
There is a way to set the SSID using DFU on each photon - does that help as an interim solution until we add this to firmware?
Ok, hereâs the deets on setting the SSID. The SSID is made of two parts - a prefix and the device serial.
Setting the SSID Prefix
The SSID prefix can be set by writing the prefix value to the device.
First, create a file that contains the length of the prefix, followed by the prefix itself. In bash, this is done like this:
echo -e -n "\x03Rad" > ssid_prefix
The \x03
writes a literal value 3 (not the ASCII character â3â) to the file - 3 being the length of our prefix âRadâ. The value is specified on the command line as hex, so values over 10 start âAâ, âBâ etc⌠The maximum allowed length of the prefix is 24.
(Thereâs no need to add a trailing â-â to the prefix, the device automatically adds a â-â between the prefix and the 6-digit serial.)
Then flash this to the device like this:
dfu-util -d 2b04:d006 -a 1 -s 1826 -D ssid_prefix
Next time the device enters softAP mode it will use the given prefix.
Setting the Device Serial
The Device Serial can be set by writing the 6-digit serial to the device.
First, create a file that contains the 6-digit device serial. In bash, this is done like this:
echo -n "ABCDEF" > serial
Then flash the serial to the device:
dfu-util -d 2b04:d006 -a 1 -s 1852:6 -D serial
Next time the device enters softAP mode, it will use the given serial.
Ok, so Iâve just done this on a Photon running 0.4.4.
Both flash operations completed correctly. But:
- The SSID change works, using your example (
"\x3Rad"
). But then I tried"\x7Example"
, and it reverts back to âPhoton.â - The device serial does update, but the broadcast AP only includes the first 4 characters of the 6-char serial.
In fact, perplexingly, nothing except "\x3Rad"
works. I tried "\x3Exa"
, and it just comes out as âPhotonâ.
Not sure what to suggest. I just tried it here with a 12-character SSID and it worked. Double check the contents of the ssid_prefix file thatâs produced with a hex editor (or use xxd to dump to binary) to be sure nothing spooky has crept in there.
Mine is a 13 byte file that looks like this:
0000000: 0c4d 6174 7468 6577 2d4d 444d 41 .Matthew-MDMA
Here you see the first byte is 0x0c - 12 - for the length of the prefix followed by the 12 prefix name characters.
Yes! Ok, it seems the problem was integers < 10 in hex representation need to be specified using a leading 0 when saved to the SSID prefix file.
So, for example, "\x7Example"
was getting saved as 7e78 616d ...
instead of 0745 7861 ...
. The fix was saving the file as "\x07Example"
.
Which OS are you using? For me the single char was working on OSXâŚbut so does 0 padded, so letâs stick to that. Iâll edit the original post.
Ubuntu 15.04
The problem was probably that the âEâ in âExampleâ is a valid hex digit. Whereas the âMâ in âMatthew-MDMAâ is not.
So, \x7Example
was getting interpreted as \x7E
+ xample
, but since âMâ isnât a hex digit (and likewise for âRâ in the âRadâ example), the shell was stopping with the last valid hex character, to give \xb
+ Matthew-MMDA
.
This only seems to interpolate the first 1 or 2 hex digits, so \xdeadbeef
results in \xde
+ adbeef
, and not the 32 bit value of 3,735,928,559.
Youâre absolutely right! It did bother me that \x3Rad had worked (which was all I had to go on initially) but not others. I guess it really just means you definitely got pad those 0âs to make sure the integers get parsed correctly.
I have following the instructions:
I have installed the DFU driver (windows x64)
The prompt, etc.
When I write:
#echo -e -n "\x03Rad" > ssid_prefix (It's OK)
When I try to upload in the dfu:
#dfu-util -d 2b04:d006 -a 1 -s 1826 -D ssid_prefix
I receive the following:
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
Filter on vendor = 0x2b04 product = 0xd006
Opening DFU capable USB device... ID 2b04:d006
Run-time device DFU version 011a
Found DFU: [2b04:d006] devnum=0, cfg=1, intf=0, alt=1, name="@DCT Flash /0x000
00000/01*016Kg"
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
No valid DFU suffix signature
#Warning: File has no DFU suffix
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000722, size = 18
.
File downloaded successfully
When I reset the device and set it on listening mode it continues appearing the standard name.
I have tried with the lib⌠driver for photon dfu and with the windows⌠driver which Zadig propose. Both options generates the same. I think it is not related with it.
I have also tried to modify the serial following your example and the name of the serial has been modified to:
Photon--n "
So, it seems the name has been (-n "), the four characters (instead of 6) before âABCDEFâ. I have modified the echo serial line from:
echo -n "ABCDEF" > serial
to:
echo ABCDEF > serial
And when I try with:
dfu-util -d 2b04:d006 -a 1 -s 1852:6 -D serial
The SSID has changed to: Photon-ABCD
In the serial it seems that the maximum is 4 letters (unless in firmware 0.4.7). It is not a problem for me.
I do not know if something related with the SSID Prefix has changed @mdma
We are ending a product development and this is possible the last step. Any help will be hardly appreciated.
Thank you very much
@Moors7: in the future, PLEASE use some formatting in your posts. This one was really hard to read.
I have just achieved in a Ubuntu 14.04 machine without problems
It would be great if you could complete @mdma instructions for Windows User.
Thanks