There is a osmocom Source and a rtl-sdr source block available in GNU Radio Companion. They seem to have the same settings. Is there a difference between them? Is one of them more up to date?
Is there a difference between them? Is one of them more up to date?
No, they are the same and here is the proof.
--- /usr/share/gnuradio/grc/blocks/osmosdr_source.xml 2019-04-25 18:14:38.000000000 +0300
+++ /usr/share/gnuradio/grc/blocks/rtlsdr_source.xml 2019-04-25 18:14:38.000000000 +0300
## -1,7 +1,7 ##
<?xml version="1.0"?>
<block>
- <name>osmocom Source</name>
- <key>osmosdr_source</key>
+ <name>RTL-SDR Source</name>
+ <key>rtlsdr_source</key>
<category>Sources</category>
<throttle>1</throttle>
<import>import osmosdr</import>
The RTL-SDR source block is effectively an Osmocom source block that has been tailored specifically for use with the RTL2832U TV tuner, also known as the "cheap software defined radio". The RTL2832U has coined this name as they can be purchased for roughly $20 USD and works fantastically despite a few limitations from cheap hardware. From what I gather, the Osmocom source block can be used with a variety of different SDR hardware, whereas the RTL-SDR source block should only be used with the RTL2832U.
Note: If you are using the RTL2832U, a custom device driver has to be loaded on prior to use with GNURadio, and can be found here.
Related
I am running gem5 version 22.0.0.2. I operate Garnet in a standalone manner in conjunction with the Garnet Synthetic Traffic injector. I want to emulate a routerless NoC so I guess I need to connect an end point (e.g, Cores, Caches, Directories) to more than one "local" router. I just use a python configuration to configure the topology. But when I do this, there is a runtime error:
build/NULL/mem/ruby/network/garnet/GarnetNetwork.cc:125: info: Garnet version 3.0
build/NULL/base/stats/group.cc:121: panic: panic condition statGroups.find(name) != statGroups.end() occurred: Stats of the same group share the same name `power_state`.
Memory Usage: 692360 KBytes
Program aborted at tick 0
Here is a description from the gem5 documentation: "Each network interface is connected to one or more “local” routers which is could be connected through an “External” link." Here is the link:https://www.gem5.org/documentation/general_docs/ruby/heterogarnet/
Here is the constructor of Stats::Group
Group(Group *parent, const char *name = nullptr)
Here is a description from the gem5 documentation: "there are special cases where the parent group may be null. One such special case is SimObjects where the Python code performs late binding of the group parent."
Here is the link:https://www.gem5.org/documentation/general_docs/statistics/api.
I guess the error may be related to this, but I don't know the exact reason.
Any help would be appreciated.
Thank you.
I'm looking if there is a way to call the board (DSXLE5) and request info of the current KeyMapping value?
It is the first time I deal with DSX5 family, I've already identified that the firmware change process is different, as before, to change a DSXLE4 8 port card to be 2in + 6out we used
$mvConnectorConfig -2in6out -sn=XXXXX
and now I see that DSXLE5 needs to point the firmware (*.pin) with the load parameter.
$mvConnectorConfig load -f=xmio5_x2_00i12o.pin -sn=xxxxx
I see from the help that we can use -KeyMapping to change the boards, but how does it work and can we call the board to show which mapping is currently using?
I'm new here, so I'm sorry if it isn't 100% straight question.
Best Regards,
Rafael Girotto
I have a VW Golf 4, which is quite old and talks KWP 2000 (ISO 9141) on its CAN bus. I use a dongle powered by ELM 327, connected to the OBD-2 port of the car.
I am trying to send messages individually to each ECU. I tried to change the header of the messages:
AT SH 48 XX F1 (I hoped XX would be the ECU ID; 48 is the flag for "use physical addressing"). Any command I issue (e.g. tried 3E for "tester present") returns NO DATA (I disabled automatic timeouts and set the timeout to maximum value).
Is there a way to send messages directly to the ECU? I am not interested in the set of data provided via OBD-2, neither do I want to re-flash the ECUs. At the moment I just try to find out which ECUs are available on the bus.
Thanks!
VW works on Transport Protocol TP 2.0, hence you need to initialize with 0x200 header.
https://jazdw.net/tp20
See above link for more info.
I would like to know, if I code an EA in a normal metatrader4 platform, can I reuse the .ex4 in other trading platform for example InstaTrader?
The reason is that, when I have created a new EA in InstaTrader, the EA code generated from InstaTrader is different from the one generated from metatrader4. And I couldn't find any documentation regarding to InstaTrader's EA.
Not sure anyone has encountered this before?
No. MQL is the language specifically for meta-editor which is a member of meta-trader platform.
Other trading languages may have their own scripting languages.
Metatrader4
In principle Metatrader4 uses a Metalang.exe that compiles the MQL4-source-code files into an "internally"-executable format EX4
As defined, EX4 is binary-executable on all Metatrader4 terminals.
.
WhiteLabel-ed Terminals
InstaTrader(TM) and many other *-Trader(TM)-s are so called White-Label modifications of the same MetaQuotes, Inc., software product, the [Metatrader 4 Terminal], that are just individually "skinned" in a name of the respective Broker, who has bought from the MetaQuotes, Inc. the license for a suite of [Metatrader 4 Server + Metatrader 4 Risk Management + Metatrader 4 Dealer Desk + ... ], inclusive, but not limited to, the right to re-label the client Terminal program.
Thus under most of the situations your EX4 code shall run on any other re-labeled Terminal
But...
Restrictions on binary-compatibility apply, as Metatrader4 terminals gets released in so called Builds, ( Build 432 -> Build 468 -> Build 509 -> ... -> Build 600 -> Build 624 ) and some of these have also modified the binary-code format.
Thus the EX4 code shall be hosted on a "similar" generation of the Terminal Build
Finally...
The ultimate show-stopper is the MetaQuotes, Inc., licensing policy, which makes a server-side locking to take place [Metatrader 4 Server] has a setting to reject connection requests from client Terminals in case their Build # is lesser than a treshold set on Server side.
There the SLM story ends. Forever.
I am referring the TRM of DM3730 and modifying the pad configurations on an EVM 3530 accordingly. I couldn't understand the following properly.
1) What are CORE power domain and WKUP power domain?
2) What is core control module and Wake-Up control module?
3) The above two questions may be completely hardware-oriented. But the reason I'm asking is, in EVM 3530 source code, in pad configurations, certain pins are defined as PAD_ENTRY and certain others as WKUP_PAD_ENTRY. What makes the difference?
#define PAD_ENTRY(x,y) {PAD_ID(x),y,0},
#define WKUP_PAD_ENTRY(x,y) {WKUP_PAD_ID(x),y,0},
#define I2C3_PADS \
PAD_ENTRY(I2C3_SCL, INPUT_ENABLED | PULL_RESISTOR_DISABLED | MUXMODE(0)) \
PAD_ENTRY(I2C3_SDA, INPUT_ENABLED | PULL_RESISTOR_DISABLED | MUXMODE(0))
#define I2C4_PADS \
WKUP_PAD_ENTRY(I2C4_SCL, INPUT_ENABLED | PULL_RESISTOR_DISABLED | MUXMODE(0)) \
WKUP_PAD_ENTRY(I2C4_SDA, INPUT_ENABLED | PULL_RESISTOR_DISABLED | MUXMODE(0))
Any kind of guidance is welcome.
WKUP provides functions for sections of the OMAP SoC to come out of power-saving mode.
A power domain can be turned on/off without affecting others (4.1.3.2). WKUP power domain is continously active, it allows for switching others. CORE power domain comprises interconnect / memory / peripheral core functions.
Wake-up control module and core control module provide for save and restore of pad configurations (7.3) when switched off.
It looks like the pads which can be configured as I2C4 SCL/SDA can also be configured with wakeup capabilities. Then in your code base (Windows CE 6 BSP?) a different macro from generic PAD_ENTRY is appropriate, probably there is an error check of (x) to confirm pad ID is valid. The non-wakeup-related macro parameters should work the same for you, there won't be a difference.
Section references are to OMAP35x-TRM.