Address Mapping parameters not saving

[holminid]

Address Mapping parameters are not saved after they are entered. This happens after "update" and "save to flash" are pressed. The new addresses stay there until the OSM is powered off, after which they return to default values (/osm/a/cv etc). It seems like they’re in place, but even then there is no response when such messages are sent to the OSM.

[pingdynasty]

So after you've changed the address mappings (e.g. Receive CV A) and pressed Update, the module still responds to the old mappings?

[holminid]

Yes, that's right.

[pingdynasty]

What address are you putting in? There's a maximum address limit of 16 characters, including slashes.

[pingdynasty]

Actually only messages 12 characters or less seem to be working at the moment, I will investigate why!

[holminid]

I enter something like /mysoftware/acceleration/1
I could really use longer addresses since I can't hard code the OSM default values in the software I'm using. Any chance of this? Thanks!

[holminid]

I managed to change the addresses output from the app which worked, but then the network connection to the OSM was lost and the addresses were also gone. Can the module be reset somehow?

[pingdynasty]

Are you able to access the web interface? There's a Factory Reset option on the Status page.
If not, try switching to AP mode (hold WiFi button down for 6 secs) and reconnect to the module's network.

[holminid]

I can't always access the web interface. I have to power off the module and wait for it to reconnect.

[holminid]

We’ve been able to reconfigure our app to use shorter OSC addresses.
We managed to get it working twice only, on both occasions the OSM crashed and lost is AP state. Power cycling the module brings the AP back but all the edited OSC addresses are lost. 
The OSM is also not saving Local Port in Network Settings, or Value Ranges on power cycling.

We tested with the TouchOSC template and everything seems to be fine, but its of no use to us really.
We cannot test with GyrOSC as their addresses are too long and cannot be saved/edited.

Any help is greatly appreciated!

[pingdynasty]

Thank you for testing this out.
I'm working on longer addresses now, and also updating the core photon firmware to the latest release. This should help with general stability.

[pingdynasty]

Crashes may be due to OSC buffer overruns. Does it help to turn off Rotation Matrix, GPS and Qaternion messages in GyrOSC?

[holminid]

We can try turning rotation matrix and GPS off but we need quaternion (do those three cause problems?)

[pingdynasty]

They may cause problems because of the total size of the message being too big. Rotation appears to be the largest with 16 float values, if I understand it correctly.

[holminid]

We just sent 5-6 signals from GyrOSC to Osculator and then OSM. These included Rotation Matrix, GPS and Quaternion. It seemed stable, the crashing problem may have been elsewhere. I saw the firmware is updated, I guess we should try that next.

[holminid]

Just to make sure - no values are saved. I can't for example use my own network settings but am forced to use AP mode. Is this being fixed?

[pingdynasty]

I've made a number of updates:

• increased max address length to 19 characters
• rewritten OSC message library: faster, lighter and more reliable
• update libraries to latest Photon version: bugfixes and improvements

If you would like to try it out please go ahead and build from master branch.
I've added build instructions here:
https://github.com/pingdynasty/OpenSoundModule/tree/master/firmware

[holminid]

Hi great! But could we please have a binary version?
Ove

On 06 Jun 2016, at 12:40, Martin Klang notifications@github.com wrote:

I've made a number of updates:

increased max address length to 19 characters
rewritten OSC message library: faster, lighter and more reliable
update libraries to latest Photon version: bugfixes and improvements
If you would like to try it out please go ahead and build from master branch.
I've added build instructions here:
https://github.com/pingdynasty/OpenSoundModule/tree/master/firmware https://github.com/pingdynasty/OpenSoundModule/tree/master/firmware
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #1 (comment), or mute the thread https://github.com/notifications/unsubscribe/ABwO593HLikr_5tECb-bcSxt37vQZ3Ruks5qI_kIgaJpZM4Isb2b.

[pingdynasty]

done - find it here:
https://github.com/pingdynasty/OpenSoundModule/releases

[holminid]

Hi Martin,

We tried to flash the firmware using the script (we installed dfu-utils from brew).

Any idea what we could have missed ?

Ove

mots:firmware mots$ ./flashMac.sh
Password:
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
dfu-util: No DFU capable USB device available

mots:firmware mots$ /usr/local/Cellar/dfu-util/0.9/bin/dfu-util -l
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Deducing device DFU version from functional descriptor length
Found Runtime: [05ac:8289] ver=0118, devnum=7, cfg=1, intf=3, path="20-3.3", alt=0, name="UNKNOWN", serial="UNKNOWN"

[pingdynasty]

The output of dfu-util -l look promising - is that the full output? Is the Photon LED flashing yellow?
I've not got an OSM here right now but will check the output against it tomorrow.

Meanwhile pls try following the instructions here: http://pingdynasty.github.io/OpenSoundModule/Firmware_Upgrade/

tl; dr: try dfu-util -d 2b04:d006 -a 0 -s 0x8020000:leave -D opensound.bin

[hdavid]

hi,

we did follow the instruction there. we indeed copied the full console output (i just removed the empty new lines to make easier to read, beside this is this the full output). We installed the dfu-utils following this http://open-txu.org/home/undergraduate-courses/fund-of-opentx-mac/installing-dfu/ and from brew. on two macs. all the same.

Is the driver for the device installed on mac by default ? it is not mentioned to install one.

regard

[pingdynasty]

Are you sure you have the device in DFU mode? Is the LED on the Photon flashing yellow?

This is the expected output from dfu-util:

$ dfu-util -l
...
Found DFU: [2b04:d006] ver=0200, devnum=15, cfg=1, intf=0, alt=1, name="@DCT Flash   /0x00000000/01*016Kg", serial="00000000010C"
Found DFU: [2b04:d006] ver=0200, devnum=15, cfg=1, intf=0, alt=0, name="@Internal Flash   /0x08000000/03*016Ka,01*016Kg,01*064Kg,07*128Kg", serial="00000000010C"

[holminid]

Yeah it’s flashing yellow. Should we have a driver?

On 07 Jun 2016, at 13:08, Martin Klang notifications@github.com wrote:

Are you sure you have the device in DFU mode? Is the LED on the Photon flashing yellow?

This is the expected output from dfu-util:

$ dfu-util -l
...
Found DFU: [2b04:d006] ver=0200, devnum=15, cfg=1, intf=0, alt=1, name="@dct Flash /0x00000000/01_016Kg", serial="00000000010C"
Found DFU: [2b04:d006] ver=0200, devnum=15, cfg=1, intf=0, alt=0, name="@internal Flash /0x08000000/03_016Ka,01_016Kg,01_064Kg,07*128Kg", serial="00000000010C"
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #1 (comment), or mute the thread https://github.com/notifications/unsubscribe/ABwO53JfK44q98HoVpA0W4bFEhd__sXHks5qJVETgaJpZM4Isb2b.

[pingdynasty]

No driver required on mac. Very strange that dfu-util is not locating the device.
Just to clarify: the tiny led on the pcb that is on the back of the module (I'm not talking about the WiFi button on the front) is definitely flashing yellow when you issue the command?
Can you try with a different computer?

[holminid]

I got it to work with another cable.

I still need to test the local wifi mode, so far I only managed to get it to work once, briefly. When I got it to work, I updated the settings, but used the button on the module panel to reset it to local mode instead of the web interface’s “reconnect” option.

Are the network settings saved entirely? The authentication method defaults to “open”.

On 08 Jun 2016, at 00:59, Martin Klang notifications@github.com wrote:

No driver required on mac. Very strange that dfu-util is not locating the device.
Just to clarify: the tiny led on the pcb that is on the back of the module (I'm not talking about the WiFi button on the front) is definitely flashing yellow when you issue the command?
Can you try with a different computer?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #1 (comment), or mute the thread https://github.com/notifications/unsubscribe/ABwO5-SswLCk482yz7HRzZeJ6c23C_Hhks5qJffggaJpZM4Isb2b.

[holminid]

I can't get the local wifi mode to work at all. I tried different networks with different authentications, to no avail. IP Scanner occasionally sees the OSM for a second (and shows the IP address) but then it disappears. AP mode works as it should, but I need to extend the network. What to do?

[pingdynasty]

Moved to #3

[pingdynasty]

Network credentials are stored securely on the device. The default of 'open' is simply due to how the html form is constructed.

[pingdynasty]

Parameter saving issue fixed in v0.9