Hi,
I was wondering if there was already a way to connect through WIFI with the Mod-Duo ?
Maybe using a USB - Wifi Key ?
thanks,
Damien
no, not yet.
the next version should have working bluetooth though.
initial tests have shown it to work quite nicely, just a bit slow to load resources. but once it’s cached (after you loaded a plugin once) subsequent loads should be much faster.
1 Like
I solved this by connecting the MOD to the router (the DSL wifi modem here also has a USB port). It needed a bit of tweaking, but this way I can move around with the laptop. The MOD has to stay put in that case.
3 Likes
Any plan in allowing Wifi connectivity (maybe via a USB dongle) in the future ? Or for the Mod X or the Dwarf ?
It would be cool to be able to use the Mod either as a device on the LAN or as a Wifi hotspot to which devices could connect (a bit like with the bluetooth currently)
WiFI dongles often needs proprietary firmware which can be problematic to distribute.
I had my fair share of pains with a few ones in my main PC.
The best way to go for this would be to pick a very few known good dongles, and mark them as the supported ones.
But would this work?
I propose it always has the wireless dongle in normal operation mode (not in “hotspot”/ad-hoc stuff) as we can connect over USB and set up the wireless network to connect to from there.
It would need a dedicated settings page/dialog though.
Or a config file to upload via ssh in the worst case. At least as a first approach 
Just go with a free software approved usb device
https://www.fsf.org/news/tehnoetic-wireless-usb-adapter-now-fsf-certified-to-respect-your-freedom
1 Like
This one should obviously be supported, but if a handful of others was (maybe with a smaller form factor), that would be great !
Quick question to @falkTX: do these proprietary firmware need to by built especially for a give architecture ?
No, firmware works as-is. it is something that the chip itself runs, so it already pre-compiled for the needed architecture inside.
Yes, that makes sense of course.
In that case, maybe there would be a way to allow the user to ssh-copy whatever firmware they need into the mod. That would take the burden away from you guys (I mean, outside of that very limited subset that you might agree to maintain on your side). Actually, all that we would be needed on the community side would be a simple tool to build the particular kernel module that we would need for a particular chipset and a simple procedure to install it inside the mod along with whatever firmware is required.
Even if the MOD kernel supports devices like this out of the box, presumably modifications to the web UI are still required in order to configure the device with the right SSID / WPA passphrase etc., right?
But even before that, as @Azza suggested, maybe there is an ugly hack involving ssh which can already work as a first step? Has anyone managed this?
I think proper wifi support might be the only way to solve the Web UI over bluetooth very slow issue any time soon …
1 Like
Don’t suppose any of the MOD team have had any more thoughts on this? IMHO this lack of decent connectivity with phones / tablets is one of the biggest weaknesses of the existing devices, and it would be awesome if at least the Dwarf could solve it. Pedals with mobile device connectivity are becoming increasingly common, and it feels like this risks being a missed opportunity assuming that it’s not too hard to address (either via wifi or bluetooth).
2 Likes
It is technically possible for sure, but not something that is going to be officially supported.
WiFi is an issue in terms of realtime audio, because to be honest most WiFi dongles are pretty shitty in terms of firmware, they can even lockup the entire kernel in some situations.
That aside, some outside/non-official work could be done for it, perhaps as a package to install somehow.
Is there some existing webserver kinda thing that can talk to wpa_client or wireless-tools on the backend or something that?
1 Like
Another idea for a workaround: Use an USB Ethernet adapter to connect the MOD device to either an existing network infrastructure, directly to another peer or a small WiFi access point or router. The last option could be used to either create a hot spot to join or for joining an existing WiFi.
I guess that it will require some minor tweaks on the console to work.
Just did some experiments here, and it is indeed technically possible…
ping timing:
$ ping 192.168.1.191
PING 192.168.1.191 (192.168.1.191) 56(84) bytes of data.
64 bytes from 192.168.1.191: icmp_seq=1 ttl=64 time=3.04 ms
64 bytes from 192.168.1.191: icmp_seq=2 ttl=64 time=3.22 ms
64 bytes from 192.168.1.191: icmp_seq=3 ttl=64 time=3.32 ms
status inside device:
[root@modduox ~]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:75 errors:0 dropped:0 overruns:0 frame:0
TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:3892 (3.8 KiB) TX bytes:3892 (3.8 KiB)
usb0 Link encap:Ethernet HWaddr F6:7C:0B:4A:AA:97
inet addr:192.168.51.1 Bcast:192.168.51.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2356 errors:0 dropped:45 overruns:0 frame:0
TX packets:1608 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:167522 (163.5 KiB) TX bytes:357830 (349.4 KiB)
wlan0 Link encap:Ethernet HWaddr ***********
inet addr:192.168.1.191 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2670 errors:0 dropped:296 overruns:0 frame:0
TX packets:5846 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:267092 (260.8 KiB) TX bytes:7917217 (7.5 MiB)
[root@modduox ~]# iwconfig
gre0 no wireless extensions.
usb0 no wireless extensions.
lo no wireless extensions.
wlan0 IEEE 802.11bgn ESSID:"**********"
Mode:Managed Frequency:2.412 GHz Access Point: 00:06:91:64:12:A0
Bit Rate=39 Mb/s Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=40/70 Signal level=-70 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:10 Invalid misc:37 Missed beacon:0
tunl0 no wireless extensions.
gretap0 no wireless extensions.
[root@modduox ~]# dmesg | tail
[ 990.480647] systemd[1]: Starting OpenSSH server daemon...
[ 990.486105] systemd[1]: Started OpenSSH server daemon.
[ 996.656793] wlan0: authenticate with 00:06:91:64:12:a0
[ 996.697203] wlan0: send auth to 00:06:91:64:12:a0 (try 1/3)
[ 996.698711] wlan0: authenticated
[ 996.698863] wlan0: associate with 00:06:91:64:12:a0 (try 1/3)
[ 996.702456] wlan0: RX AssocResp from 00:06:91:64:12:a0 (capab=0x411 status=0 aid=3)
[ 996.708960] wlan0: associated
[ 1035.798090] MOD Devices: USB Gadget disconnected
[ 1209.446141] g_ether gadget: high-speed config #1: CDC Ethernet (ECM)
We have only a couple of domains hardcoded (better said, an allow-list) in the cloud, so the new local IP is not on the list and thus cannot communicate with the cloud.
But at least all other stuff works as usual, it is possible to bring up the Web GUI.
1 Like
Nice! Mind sharing how you set that up? Looks like that was an unencrypted network? Presumably using WPA would need wpa-supplicant or similar and would be more complicated.
If you mean permanently hang the kernel, yes that is obviously a worry 
However if you just mean it could break realtime and occasionally cause a few ms of latency then that’s not such a big issue because IMHO the main use case for this is tweaking pedal boards while not playing (e.g. during rehearsals or soundchecks). Altering pedalboards mid-performance seems like a really bad idea to me.
It needs some kernel tweaks, so not something regular users can do. Then a few extra software installed and also some firmware.
I used wpa-supplicant for connecting to a WPA2 protected network.
I mean that indeed yes. Though at least here testing with a usb wifi stick that was often problematic, I did not experience any hangs.
Something like this?
Something like that yes. Though that project does not seem the best fit, plus unmaintained now.
We spoke in the team about this just now, we will add wifi support in the kernel and CLI tools to manage it.
But only if it does not affect the rest of the system.
So we can have this feature first for the few that know how to manage through SSH, and then we will see from there what is needed, how well or bad it works and all that.
The changes to the kernel config are minimal, so I think it should be fine.
Coming as experimental/advanced feature in v1.10
3 Likes
One very, very useful case for on board WIFI is the cconnectivity to Ableton Link.
The T1 from Torso Electronics is offering that: torsoelectronics.com/product/t-1
Maybe they are willing to share their experience.
I would love that as a strech goal for the Dwarf. ++++