In order to access the webserver for the radio you intend to install onboard the voxl2 you should first access the webserver when it's installed on the host pc carrier board and change the firewall settings to enable remote access. The ip address that's set as the static ip in LAN settings is the actual radio ip address. You enter that address in your browser to access the webserver, not the ip address you assigned when running voxl-configure-modem.

I recommend creating a free account on the microhard support website and downloading the product manual here:

https://support.microhardcorp.com/portal/en/kb/articles/pmddl2450-pmddl2350-pmddl2550-user-manual

It's got a pretty good walkthrough on setting up a master/slave radio configuration right up front.

Here's a pic of the general firewall settings as I have them configured. When I first tried to set up the radios I did so on the host pc carrier but when I deployed them to the voxl2 I couldn't access the webserver either. I realized the remote access is disabled by default, you have to check that middle box.

Hope this helps.file:///home/joe/Pictures/Screenshot%20from%202023-07-31%2009-37-33.png

Has anybody implemented something similar to voxl_mpa_to_ros2 that provides data flow in the opposite direction, like subscribing to the uorb topics published by px4 and exposed via ros2 topics and re-publishing them for onboard use over of the MPA? If so would you be able to point me to example code?

I'm brand new to ROS/ROS2 so I'm still trying to run through tutorials and figure out how it all works

Thanks!

Found the source of the build issues. This line in voxl-mpa-to-ros2

python3 -m pip install colcon-common-extensions lark

is installing an incompatible version of empy. See here:

https://github.com/colcon/colcon-core/issues/602

Another issue with a default sentinel/voxl2 set-up when installing ros2 I've found - need to add a sim link for libtinyxml2. I got this build error

make[2]: *** No rule to make target '/usr/lib/aarch64-linux-gnu/libtinyxml2.so', needed by 'libpx4_msgs__rosidl_typesupport_fastrtps_cpp.so'.  Stop

which I resolved via

ln -s /usr/lib/aarch64-linux-gnu/libtinyxml2.so.6 /usr/lib/aarch64-linux-gnu/libtinyxml2.so

I don't know if these issues are specific to the sentinel platform or not. I added the empy version fix to a fork of voxl-mpa-to-ros2 and will push a merge request. I'm guessing there should be a similar fix within a voxl-ros2-foxy install script or else there'll be build issues whenever trying to build a ros package onboard a vehicle that compiles ros messages (empy version issue was what was preventing me from building px4_msgs package onboard)

@jmltt nvm solved - GPIO pin 46 needs to have direction set to in or else data won't get through for some reason

one of the more recent voxl2 kernel board support package updates in the system image went from initializing GPIO46 as input to just not initializing it at all

So I'm guessing this has to do with the following I noticed in the changelog:

1.7.4
(voxl2_SDK_1.1.3)

BSP:

• add voxl-fysnc-mod kernel module
• add voxl-gpio-mod kernel module
  --- GPIO now exporting to /sys/class/gpio
• convert SE13 from 4W to 2W UART, freeing GPIO36/37
• add voxl-platform-mod kernel module
  --- see /sys/module/voxl_platform_mod/parameters
• add new target 'M0054-2' support (same rootfs as M0054-1)
• new kernel
• new devcfg.mbn

In system image 1.7.1 (SDK v1.1.2) on the drone that has no rc issues, recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi has:

&soc {
	b2b_conn_gpio_init {
		compatible = "modalai,voxl-b2b";
		pinctrl-names = "default";
		pinctrl-0 = <&tck22912G_ctrl_pin &b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 &hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &j10_lvl_shf_ctrl_pin>;
		status = "ok";
	};

	rc_in_enable_init {
		compatible = "modalai,voxl-rc-in";
		pinctrl-names = "default";
		pinctrl-0 = <&rc_in_3v3_en_pin>;
		status = "ok";
	};
};

In image 1.7.4 (SDK 1.1.3), recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi:

&soc {
	voxl_gpio {
		compatible = "modalai,voxl-gpio";
		pinctrl-names = "default";
		pinctrl-0 = <&tck22912G_ctrl_pin 
			&b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 
			&hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &hs_b2b_pin95 &hs_b2b_pin96
			&j10_lvl_shf_ctrl_pin &rc_in_3v3_en_pin &ds2_led_red &ds2_led_green &ds2_led_blue &id_som_1 &id_som_2 &id_mai_3 &id_mai_4>;
		
		modalai,gpio-init-output-high = <0 1 53 56 57 85 86 87 88 89 124 152 157 159>;
		modalai,gpio-init-output-low = <36 37 46 54 55 67 82 83 84 131 153 154 155>;
		modalai,gpio-init-input = <48 49 50 51 52>;
		
		status = "ok";
	};

	voxl_fsync {
		compatible = "modalai,voxl-fsync";
		pinctrl-names = "default";
		pinctrl-0 = <&camera_sync_110 &camera_sync_111 &camera_sync_112 &camera_sync_113 &camera_sync_114>;
		
		status = "ok";
	};
};

And then in image 1.8.06 (SDK v1.6.3) that is on the drone with the bind issues, recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi:

&soc {
	voxl_gpio {
		compatible = "modalai,voxl-gpio";
		pinctrl-names = "default";
		pinctrl-0 = <&tck22912G_ctrl_pin 
			&b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 
			&hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &hs_b2b_pin95 &hs_b2b_pin96
			&j10_lvl_shf_ctrl_pin &rc_in_3v3_en_pin &ds2_led_red &ds2_led_green &ds2_led_blue &id_som_1 &id_som_2 &id_mai_3 &id_mai_4
			&camera_sync_110 &camera_sync_111 &camera_sync_112 &camera_sync_113 &camera_sync_114>;
		
		modalai,gpio-init-output-high = <0 1 53 56 57 67 85 86 87 88 89 124 152 157 159>;
		modalai,gpio-init-output-low = <36 37 54 55 82 83 84 131 153 154 155>;
		modalai,gpio-init-input = <48 49 50 51 52 110 111 112 113 114>;
		
		status = "ok";
	};

	voxl_fsync {
		compatible = "modalai,voxl-fsync";
		pinctrl-names = "default";
		
		status = "ok";
	};
};

So the gpio initialization process changed and rc_in_enable_init was removed between SDK v1.1.2 and v1.1.3, and between SDK v1.1.3 and v1.6.3, GPIO pin 67 got moved from modalai,gpio-init-output-low to modalai,gpio-init-output-high and GPIO pin 46 got removed from modalai,gpio-init-output-low.

https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/commit/538c324713548174c8c1694680e9cba7f2d47bcb

https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/commit/ccd3893e062b03d05885da5a279be2f8d2f6c97c

Idk which change is responsible for the binding issues. I'd like to avoid flashing v1.1.3 to narrow it down. Can someone explain how the pins are meant to function for my set-up (M0094 + M0054, rc already bound)?

@Vinny Can you explain how the J10/J19, M0094 and the spektrum receiver are meant to work together?

I have a dev drone w/ VOXL2 & spektrum satellite receiver. After flashing the latest SDK (1.6.3) the receiver and transmitter stay bound but I have to force a rebind to get RC data coming in to PX4 every time I power cycle the drone. No issue up to SDK 1.1.2 and I noticed the way kernel GPIO initialization is handled changed in 1.1.3. More details here:

https://forum.modalai.com/topic/5243/spektrum-rc-bind-issues-after-sdk-update

I'm guessing this has to do with GPIO pin settings for pins 46, 67 or 159 being set wrong on boot, but I don't know enough about the hardware to understand what's going on. If I have a spektrum receiver on a dev drone w/ M0054 that is already bound to a transmitter, what should the GPIO pin settings be on boot to enable rc data flow to px4?

Ok so I've been comparing the Sentinel I have on an older SDK with no issues after power cycling with the one I just updated to the latest SDK and I noticed for the sentinel on the older SDK (1.1.2), the /sys/class/gpio only has the following

voxl2:~$ ls /sys/class/gpio/
export        gpiochip1076  gpiochip1094  unexport
gpiochip1072  gpiochip1085  gpiochip1100

where the sentinel with the latest SDK shows:

sentinel (D0006):~$ ls /sys/class/gpio/
export        gpio1152/     gpio1184/     gpio1213/     gpio1259/
gpio1100/     gpio1153/     gpio1185/     gpio1214/     gpiochip1072/
gpio1101/     gpio1154/     gpio1186/     gpio1224/     gpiochip1076/
gpio1136/     gpio1155/     gpio1187/     gpio1231/     gpiochip1085/
gpio1137/     gpio1156/     gpio1188/     gpio1252/     gpiochip1094/
gpio1148/     gpio1157/     gpio1189/     gpio1253/     gpiochip1100/
gpio1149/     gpio1167/     gpio1210/     gpio1254/     unexport
gpio1150/     gpio1182/     gpio1211/     gpio1255/     
gpio1151/     gpio1183/     gpio1212/     gpio1257/

Then I ran voxl-bind-spektrum -ds on both and get nearly identical output, the SDK 1.6.3 the spektrum bind GPIO pin for M0154 is set even thought I'm on M0054

SDK 1.6.3:

sentinel (D0006):~$ voxl-bind-spektrum -ds
Enabling debug mode
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
number of pulses: 7
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing in to /sys/class/gpio/gpio%d/direction for gpio pin 1146
read 0 from gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing in to /sys/class/gpio/gpio%d/direction for gpio pin 1120
read 0 from gpio pin 1120
An orange light should now be flashing on your receiver
If so, your receiver is successfully in binding mode

SDK 1.1.2

voxl2:~$ voxl-bind-spektrum -ds 
Enabling debug mode
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
number of pulses: 7
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing in to /sys/class/gpio/gpio%d/direction for gpio pin 1146
read 0 from gpio pin 1146
An orange light should now be flashing on your receiver
If so, your receiver is successfully in binding mode

Now the SDK1.1.2 quad shows:

voxl2:~$ ls /sys/class/gpio/
export    gpio1259      gpiochip1076  gpiochip1094  unexport
gpio1146  gpiochip1072  gpiochip1085  gpiochip1100

And SDK1.6.3:

sentinel (D0006):~$ ls /sys/class/gpio/
export    gpio1148  gpio1155  gpio1185  gpio1212  gpio1254      gpiochip1094
gpio1100  gpio1149  gpio1156  gpio1186  gpio1213  gpio1255      gpiochip1100
gpio1101  gpio1150  gpio1157  gpio1187  gpio1214  gpio1257      unexport
gpio1120  gpio1151  gpio1167  gpio1188  gpio1224  gpio1259
gpio1136  gpio1152  gpio1182  gpio1189  gpio1231  gpiochip1072
gpio1137  gpio1153  gpio1183  gpio1210  gpio1252  gpiochip1076
gpio1146  gpio1154  gpio1184  gpio1211  gpio1253  gpiochip1085

The pin settings after running voxl-spektrum-bind are the same for both vehicles in /sys/class/gpio/gpio1146 and /sys/class/gpio/gpio1259. After power cycling I'm right back where I started, but the settings for gpio1259 persist on the v1.6.3 quad.

I'm guessing I need to do something with the settings for gpio pin 46 or 159 to fix this. What should the gpio pin settings be on boot for a VOXL2 vehicle with an already bound spektrum receiver? Is the problem that /sys/class/gpio/gpio1259 settings persist between power cycles? Where are all these gpio settings getting written to on boot?

I have several Sentinels that were shipped with taoglas GPS/mag unit, ghost atto receiver, and orqa controllers with the ghost atto uberlite-24 transmitters. I also have some older sentinels that shipped with a different GPS/mag unit and the spektrum receiver/bind board.

Is there a way I could purchase the GPS/mag units, ghost atto receiver and transmitter/controller and cable assembly to the J19 connector that were used for the last iteration of the Sentinels? I don't even really care about the GPS/mag but I noticed on our newer quads there are wires from the ghost atto receiver board and the gps unit spliced together going into pin 1 of the J19 so I can't just hot swap the spektrum receiver with the ghost atto one.

I've got an older Sentinel that shipped with Spektrum RC satellite receiver and some SDK pre v1.0.0 (I think it's SDK v0.8). It hasn't been used since we got it and I was setting up for first flight. I flashed the lastest SDK (1.6.3) and went through the set up procedure, calibrated it and flew it with the same Spektrum Transmitter I've used for some other Sentinels we've been flying more regularly.

I noticed after power cycling the vehicle and transmitter (Spektrum SPM9900), the Spektrum receiver and transmitter appear to bind automatically as expected (solid orange light on transmitter and receiver light up at same time when powered on), but px4 never gets the RC data (px4-listener input_rc returns never published) until I force them to rebind by running voxl-bind-spektrum -s and setting the transmitter in bind mode.

Does anyone know what could be causing this? I don't know enough about how the spektrum bind board (M0094) works, but reading through voxl-spektrum-bind.c I'm guessing this has something to do with the GPIO pin direction settings. Did the default settings change between SDK versions? I don't have this problem with other Sentinels running SDK 1.1

@Vinny Perfect, thanks!

@Vinny That's it! I don't know how I missed it.

I couldn't find the wifi adapters that shipped with the sentinels in your store so I'm assuming you don't sell them individually.

Is this the correct one?: https://www.amazon.com/Network-AWUS036ACS-Wide-Coverage-Dual-Band-High-Sensitivity/dp/B0752CTSGD/ref=sr_1_1?crid=19AI9AU9PAJA3&dib=eyJ2IjoiMSJ9.4wHNaklwaGuY0MAbqE1jNrxAFDdMq6i1kmIRhf78QBgMpJ9jNUSm6C81R7DZLcX4QeUqQPF_yNTyNsiveKT1bFgaoIpZHBLPqVwnJzIGWP8.MZgaVZ_QxG-YQq7pd4eidSXDIZ9iYlPx2kDP1vImUD4&dib_tag=se&keywords=AWUS036ACS&nsdOptOutParam=true&qid=1772564787&sprefix=awus036acs%2Caps%2C131&sr=8-1

Does it matter what kind of adapter I get, are there any specs that I need to looks for or can I pretty much use anything?

Thanks!

@Alex-Kushleyev I just wanted to check back and see if you guys still have any of the longer cables or the entire assemblies that I could purchase. I haven't had a chance to troubleshoot the potentially bad cable, but we're just looking to replace it since we need to retrofit the older models anyways.

Again, if not no worries we make our own cables and buy the adapters it'd just be easier to buy ready-made sets.

@Alex-Kushleyev That is the type of cable I'd need but I've actually ordered that one (MCBL-00009-1) before for a separate application and just eyeballing it it's about half the length I'd need. Here's a picture of the set-up

Also, in addition to trying to troubleshoot this adapter/cable I need to retrofit four older Sentinel models (were only shipped with the microhard carrier board, no wifi adapter) with wifi adapters so if it's possible I'd like to just purchase five assemblies (usb to jst and wifi adapter shrink wrapped together). If you guys don't have any of that cabling already made or there's no mechanism for me to order them as a set that's totally fine. We can order the piece parts and make the cabling ourselves, it'd just be easier for us to order them if that's possible.