For RAK2247,what we are used is only PCIe Form factor,not PCIe interface standard definition.So,usually the net connected to Pin22 is a GPIO from HOST,not PERST of PCIe interface.
Of course,we can populate R50 and Q12 and remove R136 if you want to use active low for the reset.But this kind of products need to be customized and we will deal with them before sending them to you.
By the way,do you use SPI or USB interface RAK2247?If you use USB interface RAK2247,you can reset SX1301 by USB(FT2232’s ADBUS5, remove R136).
1.Usually,Customers only use USB interface.No need to remove R136 because there is no connection to PIN22 of PCIe connector.
2.The USB to SPI IC is FT2232HL.You can set Pin22 of FT2232HL High to do reset if you have drivers of FT2232HL intergated in your X86 board.
Do you have a example of how you would do this with the correct drivers?
Currently lsusb give me:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 046d:c315 Logitech, Inc. Classic Keyboard 200
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
We have a card and want to modify the reset by removing R136 since our slot does have PCIe Reset mapped to that pin. Can you point out on the back of the card where R136 is (hopefully it’s not on topside with shield)? I was able to find the transistor that isn’t loaded near the large cap.
As I read @Jeff answers if it is a USB only board, the PIC port pin 22 is not connected on the RAK board. But on another device where I can control PIC port pin 22 running the standard reset script allows lora_pkt_fwd to start the concentrator???.
But I push forward and am trying to reset through software and drive the ADBUS5 gpio High (FT2232HL pin 22).
I’m currently trying to do that with python (pyftdi)
Note this is still a work in progress and doesn’t solve the problem yet:
from os import environ
from time import sleep
from pyftdi.gpio import GpioController, GpioException
if __name__ == '__main__':
gpio = GpioController()
url = environ.get('FTDI_DEVICE', 'ftdi://ftdi:2232/1')
# ADBUS0 | In | 0
# ADBUS1 | In | 0
# ADBUS2 | In | 0
# ADBUS3 | In | 0
# ADBUS4 | In | 0
# ADBUS5 | Out | 1
# ADBUS6 | In | 0
# ADBUS6 | In | 0
# 0000 0100 == 0x04
mask = 0x04
on = mask &= 0xFF
off = mask &= 0x00
so it looks like ADBUS5 is switching, but then running lora_pkt_fwd gives the same result
ERROR: Failed to load fw 1
ERROR: Version of calibration firmware not expected, actual:0 expected:2
ERROR: [main] failed to start the concentrator
to find your url use:
Python 3.6.8 (default, Oct 7 2019, 12:59:55)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pyftdi.ftdi import Ftdi
ftdi://ftdi:2232/1 (Dual RS232-HS)
ftdi://ftdi:2232/2 (Dual RS232-HS)
Please specify the USB device
in my case ADBUS* gpio should be on ftdi://ftdi:2232/1
It’s unclear to me if the resistor that would connect the FT2232H to the SX1301 reset is normally installed, but if it is, you don’t need to write any python code to manipulate it, as the code in the FTDI-compatibility-reverted version of the lora gateway library already does that:
Your attempts would probably be undone by this anyway.
Also, don’t jump right to running the packet forwarder, run the spi tests from the lora gateway library first.
In one were desperate to disconnect the reset from the PCI bus, the picture in this thread shows a via right above the relevant edge finger, a moment with a drill bit twisted in ones fingers would break the connectivity, but that is likely to be fairly permanent. It’s possible you could get the card into a socket with a piece of kapton tape over the relevant finger(s) - likely not much nearby is needed.
Or consider putting the card in an external GSM modem mPCIE to USB adapter (just make sure the regulator isn’t set to output an unusually high voltage, as many of the cheap ones seem to be)