How to measure RSSI/SINR with simu5G in Omnet++ - omnet++

I want to measure the RSSI of the individual users in a 5G wireless scenario (particularly, I am following the standalone_multi-cell example from the simu5G module).
Can anyone suggest how to do it? I have tried the following answer-
OMNET++: How to obtain wireless signal power?
And its working for INET wireless tutorial.But I could not figure out how to apply this in the simu5G? (standalone_multi-cell example). What am I missing?
I really appreciate any help you can provide.
Moyukh
I have tried the following
OMNET++: How to obtain wireless signal power?
And its working for INET wireless tutorial.But I could not figure out how to apply this in the simu5G? (standalone_multi-cell example). What am I missing?

Related

Using Pin 26 for ADC?

Using pin 26 for ADC seems to be discouraged in Toit.
From what I can see on https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html pin 26 should have an ADC converter, so what is the reason for that?
The ESP32 is limited around ADC2:
Since the ADC2 module is also used by the Wi-Fi, only one of them could get the preemption when using together, which means the adc2_get_raw() may get blocked until Wi-Fi stops, and vice versa.
Therefore I suggest using ADC1-pins if WiFi is used for connectivity.
Since All ADC2 Pins Can't be used while using WIFI, You can use ADC1
GPIO32 ADC1_CH04
GPIO33 ADC1_CH05
GPIO34 ADC1_CH06
GPIO35 ADC1_CH07
GPIO36 ADC1_CH0
GPIO39 ADC1_CH03
Check this video to learn more about esp32 pins and assigned pirepherals:
https://www.youtube.com/watch?v=LY-1DHTxRAk&t=546s

How to determine communication range in Omnet++ 5.6.1 and Inet 4.2

I use the following instruction in omnetpp.ini, but I get the "Unused entry (does not match any parameters)" warning.
*.host*.wlan[0].radio.transmitter.communicationRange = 500m
How to set the communication range? Also the interference range?
Getting that warning may or may not be a problem (the IDE cannot always figure out the exact type of a module, so false positive warnings about unused parameters are to be expected). It depends on the rest of your code. The INET wireless tutorial should give you ample examples how to configure your wireless network.

micropython ds18x20 wrong rom/address/serial

I have ESP23 dev kit with micropython firmware esp32-idf3-20200329-v1.12-317-g688323307.
I also have ds18b20 waterproof sensor. datasheet link
I wrote this code for it:
import time, onewire, ds18x20
import machine
from machine import Pin
ds_pin=Pin(19)
ds_sensor = ds18x20.DS18X20(onewire.OneWire(ds_pin))
roms = ds_sensor.scan()
for rom in roms:
print(rom)
It returns tis info:
[bytearray(b'(\xbcN6\x14\x19\x01\xba')]
Before reading temp data from sensor, we first need to use the scan() function to scan for DS18B20 sensors. The addresses found are saved on the roms variable (the roms variable is of type list). scan() function sends request and sensor returns its unique 64-bit serial code.
I used manual here
Today I bought two more ds18x20 waterproof sensors (I don’t know what type of sensor - ds18a20/ds18b20 or else - are they, ‘cause eager chinese manufacturers sealed sensors inside metal bullet too good, so I can’t just look inside).
I tried to run the same code with them, but it returned the following:
bytearray(b'(\xff\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xfe\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xfc\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xf8\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xf0\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xd0\xff\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xff\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xfe\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xf6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xe6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xc6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xff\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xfd\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xf9\xff\xff\xff\xff')
bytearray(b'(\x90\x86y\xff\xff\xff\xff')
bytearray(b'(\x90\x86y\xfe\xff\xff\xff')
bytearray(b'(\x90\x86y\xfa\xff\xff\xff')
bytearray(b'(\x90\x86y\xf2\xff\xff\xff')
bytearray(b'(\x90\x86y\xe2\xff\xff\xff')
bytearray(b'(\x90\x86y\xa2\xff\xff\xff')
bytearray(b'(\x90\x86y\xa2\xfd\xff\xff')
bytearray(b'(\x90\x86y\xa2\xf9\xff\xff')
bytearray(b'(\x90\x86y\xa2\xf1\xff\xff')
bytearray(b'(\x90\x86y\xa2\xe1\xff\xff')
bytearray(b'(\x90\x86y\xa2\xc1\xff\xff')
bytearray(b'(\x90\x86y\xa2\x81\xff\xff')
bytearray(b'(\x90\x86y\xa2\x01\xff\xff')
bytearray(b'(\x90\x86y\xa2\x01\xfb\xff')
bytearray(b'(\x90\x86y\xa2\x01\xf3\xff')
bytearray(b'(\x90\x86y\xa2\x01\xe3\xff')
bytearray(b'(\x90\x86y\xa2\x01\xc3\xff')
bytearray(b'(\x90\x86y\xa2\x01\x83\xff')
bytearray(b'(\x90\x86y\xa2\x01\x03\xff')
bytearray(b'(\x90\x86y\xa2\x01\x03\xfe')
bytearray(b'(\x90\x86y\xa2\x01\x03\xfc')
bytearray(b'(\x90\x86y\xa2\x01\x03\xdc')
bytearray(b'(\x90\x86y\xa2\x01\x03\\')
When I try to read temperature using this values it returns ‘CRC error’.
What can be done? Is the problem with code, or the sensors are failed somehow?
Connect one sensor at a time when you do the scan.
You haven't shared how you're wired the DS18x20 sensor. Make sure its positive power connection is to 3.3V not 5V.
Make sure you've connected a resistor (4.7K should be good) between the data pin of the sensor and 3.3V. OneWire devices absolutely won't work reliably without this resistor - you might see the kind of problem you're seeing.
If you're sure it's wired correctly the next step would be to try it with different firmware, for instance a Dallas one-wire scanner using the Arduino Core. That would eliminate the possibility of problems with the library you're using and MicroPython.
looks like fake sensor
How to tell original from fake DS18B20 temperature sensors
Looks like i'm a fool))
Yes. One 4.7K pull up resistor and it's alive! IT'S ALIVE!!
aaaand whats'up doc?
then we use internal PULL_UP mode we pull up signal only for ESP.
BUT! DS18B20 is microchip too. And the wire for little DS18B20 is like giant radio aerial.
Maybe in my first sensor this problem was solved on hard level.

Any example useage of a BSCANE2 primitive in Xilinx 7 series? (using the JTAG port to configure user design)

I've looked over the info on BSCANE2 in http://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf (pg 169 7 Series FPGA Configuration Guide) and I can't quite figure out how to use it based on that descriptions.
I want to be able to use the JTAG port on the KC705 board to shift in some configuration data for our design. I think (based on the description there in the user guide linked above) that the BSCANE2 is what I need to do that... but I really don't understand why all of the pins of the BSCANE2 component seem to have the wrong direction (TDO is an input while all of the other JTAG control sigs like TCK, RESET, TDI are outputs). Initially I had thought that there was an implicit connection from the signals of the JTAG port of the FPGA to the instantiated BSCANE2 component, but that doesn't appear to be the case based on the port directions. I suspect I'm missing some information somewhere and while I have read the docs it's still not clear to me how to actually use the BSCANE2 to do what I'm trying to do.
Any example usage of a BSCANE2 component would be appreciated.
NOTE: the description of the BSCANE2 in the user guide linked above says:
The BSCANE2 primitive allows access between the internal FPGA logic and the JTAG Boundary Scan logic controller. This allows for communication between the internal running design and the dedicated JTAG pins of the FPGA
This sounds exactly like what I need.
Xilinx offers a 8 bit CPU called PicoBlaze that uses a JTAGLoader module to reconfigure the PicoBlaze's instruction ROM at runtime. The JTAGLoader is provided in VHDL for Spartans and Series-7 devices.
But I think JTAG is not a good protocol for data transfer. Especially the JTAG software API is a mess.
What about UART? Most boards have a USB-UART bridge like CP2103 that supports up to 1 MBoud.

GPIO pins will not toggle (high/low) on beagleboard xm

I am trying to use the expansion header to control a couple motors and auxiliary task mechanism. For this I am using the appropriate pins as GPIO and merely attempting to send high or low signals as needed by the robot. (For instance, I might need the robot to move forward and so I'd send high signals on both sets of pins, whereas if I needed the robot to turn I'd send a high signal to one pin and a low to the other.)
However, the problem is that the pins will only stay high! I've followed the conventions for sysfs just via the terminal, and, although I'm able to set the "values", "active_lows", etc. to 0 or 1, I can't actually get the pins to send 0V. After checking the beagle.h file I used for u-boot it looks like the multiplexer mode is configured correctly. This is also reflected when I get the info from sys/class/gpio/gpio%/% and sys/kernel/debug/gpio. Furthermore I don't get any errors or indication from anywhere that there is something wrong...it just doesn't work!
What should I do? For the first time in my life I have seemingly exhausted the internet...
details:
Beagleboard xm rev c1
ubuntu 12.04
kernel 3.6.8-x4
Im pretty new to the beagle board and I have recently been trying to configure the GPIO pins on my classic beagleboard c4, which i believe should be fairly similar.
Half of my GPIO pins seemed to work fine and the other half seemed to remain high or low no matter what i did. Even though they were configured the same way as the working pins in /sys/class/gpio/
have you tried to use other gpio pins?
I ended up following http://labs.isee.biz/index.php/Mux_instructions
to configure the mux to 4 and now i can control the pins that were not working.
I basically used the command:
sudo echo 0x004 > /sys/kernel/debug/omap_mux/(mux 0 name)
where (mux 0 name) was the name of the subsystem for the mux 0 setting for the gpio pin you wish to configure
ie. for gpio 183 on beagleboard c4
sudo echo 0x004 > /sys/kernel/debug/omap_mux/i2c2_sda
Though I had to change permissions to modify these files
As I said I am pretty new to the beagleboard and ubuntu but this worked for me so I thought I would share it with you, I hope it is of some help.
Regards;
Paul;
It seems that the beagleboard expansion pins are numbered in alternating fashion, as clearly and professionally depicted here.
Thanks to everyone for your help. I now know way more than I should about GPIO on OMAP systems (and so do you). Good luck on finals/life!**
tl;dr I'm an idiot!

Resources