Do you know how to set up the Spreading Factor to 12 in a Mbed-OS LoRaWAN protocol APIs to connect to a LoRaWAN network using OTAA?
I'm trying to make LoRA node to use Spreading Factor SF12, because the default one is SF7. I know that in the PHY layer we can change Radio configurations. There are several examples to change between the different sub-GHz frequency bands, however, I can't find one on how to change the LoRa modulation SF between 7 and 12 and with a bandwidth of 125 kHz.
I'm using an SX1276 radio at EU 868 MHz config.
In the source code you can find the SF7-12 different configurations, but there is not a clear way to set it up. These configs are the definitions (#define) DR_0, DR_, etc ).
In the configuration file in the Phy part you find some example like this:
"phy": {
"help": "LoRa PHY region. 0 = EU868 (default), 1 = AS923,
2 = AU915, 3 = CN470, 4 = CN779, 5 = EU433,
6 = IN865, 7 = KR920, 8 = US915, 9 = US915_HYBRID",
"value": "0"
},
But there is no examples or description for the Spreading Factor.
I would like to change it via source code, rather than the configuration file.
EDIT 1:
after Jon's answer, I add the following lines, but still not forcing the SF12 Joins.
retcode = lorawan.disable_adaptive_datarate ();
retcode = lorawan.set_datarate (0); // DR_0
Call:
lorawan.set_datarate(0); // SF12 125 KHz
Make sure to:
Disable ADR.
Either use ABP, or call the function above in the JOIN_SUCCESS event handler. This is because join procedure always starts at SF7, and then keeps the data rate on which the join succeeded.
Related
I need to measure link delay in Ryu controller. I want to send a packet-out message for all switches by the controller and calculate the time between the sent packet-out message and received the packet-in message. I am a beginner in Ryu and don't know how to send a packet with specific EtherType such as 0x8fc to all switches. I have obtained the MAC of all switches and build a packet. how I can send a packet with specific EtherType to all switches? I don't know what is the db parameter for every switch?
def send_packet(self, dp, port, pkt):
ofproto = dp.ofproto
parser = dp.ofproto_parser
pkt.serialize()
data = pkt.data
action = [parser.OFPActionOutput(port=port)]
out = parser.OFPPacketOut(
datapath=dp, buffer_id=ofproto.OFP_NO_BUFFER,
in_port=ofproto.OFPP_CONTROLLER,
actions=action, data=data)
dp.send_msg(out)
def create_packet(self):
i=l=0
for l in range(1,len(self.adjacency)+1):
#print("\n")
for i in self.adjacency[l]:
ethertype = 0x8fc
dst = self.macaddr(i)
src = self.macaddr(l)
e = ethernet.ethernet(dst, src, ethertype)
p = packet.Packet()
p.add_protocol(e)
p.add_protocol(time.time())
p.serialize()
port=self.adjacency[l][i]
send_packet(self, dp **??????** , port, p):
DP is the abbreviation for DataPathID that is kind of Uniq ID for an OpenFlow switch in your network.
According to the OpenFlow specification:
“The datapath_id field uniquely identifies a datapath. The lower 48
bits are intended for the switch MAC address, while the top 16 bits
are up to the implementer. An example use of the top 16 bits would be
a VLAN ID to distinguish multiple virtual switch instances on a single
physical switch.”
If you're using Mininet and for example, you run linear topology:
mn --controller remote --topo linear,3
Your topology will be:
s1 -- s2 -- s3
| | |
h1 h2 h3
DataPathID's will be:
s1: 0x0000000000000001
s2: 0x0000000000000002
s3: 0x0000000000000003
Pay attention that in other testbeds this numbers may be different but they're alway 16 digit hex.
There have been a few posts on this issue without any solutions announced.
Wanting to access internal movesense sensor data (ECG, Acc…) but without using the Android or iOS platforms ( as suggested by a movesense presentation https://www.movesense.com/wp-content/uploads/2018/11/2018-11-06-Using-Movesense-CustomGATTService.pdf ), I have failed to do so for at least 1 week.
I can successfully create my own GATT characteristics and subscribe to them from outside the movesense device. This is easily done by augmenting the samples/custom_gattsvc_app with a few lines :
Definition :
const uint16_t myCharUUID16 = 0x2A58; // this new characteristic will appear in the service as the third one in the sample
In CustomGATTSvcClient::configGattSvc() :
WB_RES::GattProperty myCharProp = WB_RES::GattProperty::INDICATE;
myChar.props = wb::MakeArray<WB_RES::GattProperty>( &myCharProp, 1);
myChar.uuid = wb::MakeArray<uint8_t>( reinterpret_cast<const uint8_t*>(&myCharUUID16), 2);
customGattSvc.chars = wb::MakeArray<WB_RES::GattChar>(characteristics, 3); // 3 here since there are 3 characteristics now
Accessing
You can now see and subscribe with a BTLE client (bluetility…) to the new service even if it does not do anything for now.
The problems start here for me :
In CustomGATTSvcClient::onGetResult() I try to force a subscription to ECG or Acc since onGetResult() is called by CustomGATTSvcClient::onPostResult() once all the BT services are created :
int32_t sampleRate = 10;
asyncSubscribe(WB_RES::LOCAL::MEAS_ACC_SAMPLERATE(),AsyncRequestOptions::Empty, sampleRate);
I do not implement onSubscribeResult()
In onNotify() you should be able to intercept the call from the whiteboard with the new data every 1/10 second by
switch (resourceId.getConstId()) {
case WB_RES::LOCAL::MEAS_ACC_SAMPLERATE::ID:
{
// To see a blinking LED on each new Acc data
asyncPut(WB_RES::LOCAL::COMPONENT_LED(),AsyncRequestOptions::Empty, myFlippingBool);
myFlippingBool = ! myFlippingBool;
}
What I have observed :
A. When I asyncSubscribe() the ECG or Acc, the sample’s WB_RES::LOCAL::MEAS_TEMP::LID is no longer called and no updates are dispatched to a BT client even after a successful subscription to the 0x2A1C characteristic. This means that all Notifications are disabled by a resource conflict ?
B. When subscribing ( as before ) or even by :
wb::Result result = getResource("Meas/Acc/10", mMyAccResourceId);
result = asyncSubscribe(mMyAccResourceId);
The onNotify() method is never called as the LED does not blink ( even directly after onNotify() implementation without the switch / case )
There is a lack of documentation on CustomGatt and it seems it blocks many people in integrating the sensor on other platforms ( Raspberry Pi or generic processors running a BT stack ).
I have tried before to access the movesense platform with direct AT commands from a rudimentary microcontroller and a BT module without success (Movesense direct access to GATT endpoints ), so now I’m turning to a Raspberry solution + Qt without success.
Thank you for any example or answers to this question !
At least 10 Hz is not supported. What happens with Meas\Acc\13 ?
I have a .rrd db which is collecting data from a temperature gauge. Now I have a second gauge so I'd like to add this new gauge to the existing .rrd database. I tried many times with the "rrdtool tune" command, but after that I run a "rrdtool info" on my database, and I see that there's not the last data source (another gauge) that I tried to insert.
How can I do this?
The command you need is, as you say, rrdtool tune. The documentation is available online at https://oss.oetiker.ch/rrdtool/doc/rrdtune.en.html
The ability to extend an RRA and to add or remove a DS was only added late in RRDTool 1.4. Check that you are not using an older version of RRDTool, as if you are, you will not be able to use this feature until you upgrade.
I just checked, and I see I'm using RRDTOOL 1.4 so I would not have problems. Anyway, the fact is that I used this command:
/usr/bin/rrdtool tune TEMPCucina.rrd DS:METEOTEMPEXT:GAUGE:1200:U:U RRA:AVERAGE:0.5:1:180000
I got this back from the computer:
DS[TEMPCucina] typ: GAUGE hbt: 1200 min: nan max: nan
But it seems that I'm not able to write into TEMPCucina.rrd
And if I try to perform the following command:
rrdtool info TEMPCucina.rrd
I just get the following, and it seems that no new gauge has been created
filename = "TEMPCucina.rrd"
rrd_version = "0003"
step = 60
last_update = 1510780261
header_size = 556
ds[TEMPCucina].index = 0
ds[TEMPCucina].type = "GAUGE"
ds[TEMPCucina].minimal_heartbeat = 1200
ds[TEMPCucina].min = NaN
ds[TEMPCucina].max = NaN
ds[TEMPCucina].last_ds = "18"
ds[TEMPCucina].value = 1,8000000000e+01
ds[TEMPCucina].unknown_sec = 0
rra[0].cf = "AVERAGE"
rra[0].rows = 30000
rra[0].cur_row = 1304
rra[0].pdp_per_row = 1
rra[0].xff = 0,0000000000e+00
rra[0].cdp_prep[0].value = NaN
rra[0].cdp_prep[0].unknown_datapoints = 0
(when I try to write I get this, but I don't know how to proceed at this point)
ERROR: TEMPCucina.rrd: illegal attempt to update using time 1510780527 when last update time is 1510780527 (minimum one second step)
I finally did it, but I wasn't able to use the rrdtool tune function.
I finally found here how to perform a dump of the database, how to modify it, and finally restore it to its original location (so I could also correct some data).
This is not what I was searching for, but it solved my problem so I want to share it.
I used STM32CubeMX version 4.22 to generate MSC usb device and modified it to have 2 custom bulk interfaces. Interface 0 has 2 BULK endpoints IN and OUT. Interface 1 have two alternate settings. Alt Setting 0 has 0 endpoints and Alt Setting 1 have 2 BULK endpoints IN and OUT.
Endpoints are defined as :
define INTERFACE0_IN_EP 0x81
define INTERFACE0_OUT_EP 0x01
define INTERFACE1_IN_EP 0x82
define INTERFACE1_OUT_EP 0x02
My device enumerates fine and Interface 0 works as expected. Host sends Set Interface 1, Alt Setting 1 request then i activate Interface 1 endpoints (0x82 and 0x02).
Interface 1 is not working as expected, i am sure it has something to do with my FIFO Settings. I get dataOut Call for INTERFACE1_OUT_EP but when i try to write INTERFACE1_IN_EP host only get 3 bytes back while i am writing 24 bytes. Immediately after this transaction i get CLEAR FEATURE request for interface 1 endpoints.
Here is my current FIFO Settings :
HAL_PCDEx_SetRxFiFo(&hpcd_USB_OTG_FS, 0xC0); //80
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 0, 0x40); //EP0
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 1, 0x80); //EP1
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 2, 0x40); //<-- If i don't add this line Host can not get any thing back, After adding this line host only receives 3 bytes on INTERFACE1_IN_EP.
Please help me to configure these FIFO settings properly so that second interface can also work as expected.
There are only 0x140 x 4(=1280bytes) available for USB FIFO in STM32.
But you used 0x180(=c0 + 40 + 80) x 4(=1536bytes).
I need a simple and cheap "PLC" or another device to execute very simple task based on hardware input and outputs.
The goal is to simulate "switchgear" in a high voltage power substation, breakers and disconnectors.
Basicly it gives feedback of the device when in "open or closed state" based on "open and close commands" given
There are 7 devices in a bay, so there should be:
14 inputs for commands (7 open and 7 close commands)
14 outputs for states (7 open and 7 closed states)
The hardware input and outputs should handle 220V DC.
A small monitor or LEDs to show the states would be preferable.
I know this can be done with "simple relay technique", but the relays I can find capable for this are pretty expensive and pretty huge.
I also know it can be done by programming, and here is the basic idea of the code:
Variable_A = 0 'There should be 7 variables, so a copy of the entire code with variables A to G
If Hardware-input 1 'open command
Set Var_A: 0
delay 2s 'delay to
Set Var_A: 1
If Hardware-input 2 'close command
Set Var_A: 0
delay 2s
Set Var_A: 2
Case
Var_A = 0 'between state
Hardware-output1 = 0
Hardware-output2 = 0
Var_A = 1 'open state
Hardware-output1 = 0
Hardware-output2 = 1
Var_A = 2 'closed state
Hardware-output1 = 1
Hardware-output2 = 0
Var_A = 3 'illigal state
Hardware-output1 = 1
Hardware-output2 = 1
What I thought of is a Siemens DIN-rail PLC or a raspberry PI with external inputs/outputs.
So Im asking if anyone can recommend a good solution to this?
I was suggested Arduino and this seems like a perfect solution.
I believe you should ask this question in the Electrical Engineering Stack Exchange.
220VDC would be very unusual for a PLC.A common PLC with 24VDC Input and output will be a cheaper option.To use conventional 24VDC PLC I/O, you could place solid state relays or opto-couplers between the field devices and the PLC.