I have a question about my CAR's ODB function.
I have a USB dongle with AT90CAN128 uE , the uE has CAN driver and i can use this to read the data traffic on the bus.
I have a BMW 116i but this car uses KWP-fast protocol for the obd2.
I want to ask if can i use the CAN bus to send queries to the ECU for the obd2 available variables.
I am not sure because at work we use the KWP2000 protocol via CAN bus, but i don't have the specification, we use a ready tool on CANoe.
KWP2000 is not CAN, they are completly different. OBD2 includes CAN and KWP2000 (also J1850, among others). They use a different physical layer and you won't be able to use CAN to listen/talk KWP2000.
Related
I would like to create a point-to-point connection between a LoRa temperature sensor and a M5 Stack (ESP32) with LoRa module. However, I am a beginner with LoRa, so I have a few questions:
Are all packets send with LoRa (not LoRaWAN) encrypted? Or does it depend on the producer of the LoRa sensor?
Can the content of the packet received by the M5 Stack be viewed? (If I understand correctly, with the LoRaWAN the content can only be viewed after it is on the server).
Can I send measured temperatures from multiple LoRa sensors to one M5 Stack? If yes, how could I distinguish from which sensor the packet has been sent?
Any help would be appreciated!
LoRa means only the RF modulation. All crypto happens in higher layers, i.e. the protocol stack – one possible option for this is LoRaWAN. LoRaWAN uses AES-128 encryption in two layers, Network and Application. You gave no information about the kind of "LoRa temperature sensor" you have, so it is not possible to make a statement about that, other than that it is not LoRaWAN. So this fully depends on the sensor's firmware. There are alternative protocol stacks to LoRaWAN, DASH7 for example. You also might want to have a look at this Stack Overflow article
This too depends on the used protocol stack. With LoRaWAN, you need a gateway to receive the node's LoRa telegrams which are then forwarded to the LoRaWAN cloud (TTN/TTS, for example). Your application can get them from there via Internet. If there's already a TTN gateway in reach, your nodes would automatically use that.
You can actually use the M5 with its WLAN capability to act as a message consumer for multiple nodes by subscribing to the cloud via MQTT, for example – using LoRaWAN. Using LoRa without LoRaWAN, this again depends on the alternative protocol stack you are using here. Of course this requires a working WLAN in reach.
If you are trying to use plain LoRa, which is possible, it is purely your task to implement all the requirements for managing the communication between all involved nodes; it is also your responsibility to ensure that the legal obligations are met.
I would strongly recommend using LoRaWAN and TTN/TTS as it is the de-facto standard for LoRa communications and offers a complete ecosystem that can be used readily without great effort/cost.
I have elm327 v2.1 bluetooth and wifi usb dongle. I want to read steering angle from a car.
OBD2 PID standards do not include this data.
So I cannot get them by asking PID.
I tried to sniff the traffic , but I wasn't able to do it with this hw yet. With AT commands I used ATMA command to read CANBUS communication inside the car, but it mostly includes OBD2 PID type messages.
CAN protocol control block in every hardware's has a block which it name is can id filter and can id mask. this block filter can massages, and just access the massages that device need , this help micro controllers to don't wasting time on Unnecessary packets.
so ELM327 cant sniff traffic ,because can filter block dont let that to see traffic
it just see the packets that can id filter access , the packets that them id is 7xx
I know that MAC address is used for local routing and error free data transfer, but is it used regardless the transmission medium infrastructure? I know it is used for Ethernet, but is it used for fiber, copper...etc?
Also, do we use MAC address when routing traffic between two adjacent routers? If we do, does that mean we have MAC address over serial connections?
Thanks
MAC addresses are used in most IEEE 802 network technologies, like Ethernet (802.3) and Wifi (802.11), but not all technologies use them. For instance, Fibre Channel use a different and more modern address type, called World Wide Name. It's longer and can be 64-bits or 128-bits.
So, to answer your questions, a router can use MAC addresses if it forwards packets over Ethernet interfaces, regardless of the physical medium. But it could also use other technologies or even label-switching protocols like MPLS. A serial link does not have medium access control and therefore has no MAC layer.
is it used regardless the transmission medium infrastructure? I know it is used for Ethernet, but is it used for fiber, copper...etc?
You mix OSI layer 1 (transmission medium) and layer 2 (Ethernet). If we use Ethernet as our data link layer, Ethernet MAC addresses will be there regardless of transmission medium. More on that on Wikipedia:
https://en.wikipedia.org/wiki/OSI_model
do we use MAC address when routing traffic between two adjacent routers?
Yes, if the router are connected using Ethernet. Even if we use a back-to-back cable to connect two routers.
does that mean we have MAC address over serial connections?
For the most of serial connections we do not use Ethernet, but use other layer 2 protocols, like ppp, Frame-Relay or HDLC. Note, that all of those protocols use their own addressing, but it is just one or two bytes, not 6 as in the Ethernet MACs. More on those protocols on Wikipedia:
https://en.wikipedia.org/wiki/Point-to-Point_Protocol
https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
https://en.wikipedia.org/wiki/Frame_Relay
MQTT and CoAP are being promoted as standard protocols that allow connecting constrained devices to the Internet.
I'm interested in a list of sensors and actuators that support these two protocols either in a native way or through a mesh/gateway.
For CoAP:
Every 6LowPAN sensor mote have a CoAP client,
for example the one running contiki: http://www.contiki-os.org/hardware.html
or OpenWSN, RIOTOS
Also you can use any Arduino: https://github.com/1248/microcoap
One that is worth checking in addition to Julien's List is mBed from ARM
https://mbed.org/
it supports both CoAP and MQTT
CoAP/MQTT and sensors/actuators are two different entities. You can implement any sensors or resources with CoAP and MQTT.
CoAP and MQTT are application layer protocol that uses TCP/UDP to transfer data (for example, sensor readings) over network.
For example in CoAP, all sensors on your hardware are treated as 'resource'. CoAP provides GET, PUT, POST, DELETE interface to manipulate with resource.
It is developers responsibility to attach its custom handlers to above interface. For example, attach read_temperature_sensor_data() to 'GET' interface, attach set_clock_time() to 'PUT' interface etc.
Have a single PCI device which contains three NICs, courtesy of Altera Ethernet cores. Must implement for WinXPe thus NDIS 5.1. MVPs have suggested implementing a WDM driver for each core, then a single NDIS driver that talks to the individual WDM drivers, which I do not understand, given that a single NDIS driver does not appear to have any concept of multiple ports or channels.
What if at DriverEntry the NDIS driver called NdisMInitializeWrapper once for each ethernet core? It would need to call each time with the same DriverObject, but would presumably get back a different NdisWrapperHandle with each call. That unique NdisWrapperHandle could be used as a context specifier for calls to all other NDIS driver functions.
That won't work; NdisMInitializeWrapper can only be called once per driver.
The rule is: you need to have one device node per network interface. Therefore, if you want 3 Ethernet interfaces, you'll need 3 device nodes in the system. There are a couple ways to get there:
The PCI bus will create a device node for each PCI function number. If your PCI device exposes 3 functions to the bus, then Windows will enumerate 3 miniport device objects. This makes the driver super simple. But, obviously, you have to be able to rejigger the hardware to do this.
Alternatively, if you are stuck with only one PCI device with one PCI function, then you need to multiplex the PCI-enumerated device node yourself. This means you should create your own Virtual Bus Driver (VBD). The PCI bus enumerates one device node, which is associated with the driver for your VBD. Then your VBD turns around and enumerates 3 child nodes, each of which is associated with a miniport.
This approach takes considerably more work, since now you need to write two drivers. Fortunately, WDF makes writing a bus driver possible for mere mortals. Your VBD needs to implement code to share resources (interrupts, config space) among the child network miniports.
The big-name vendors are split on whether they chose option #1 or option #2, so both can work. From your description, it sounds like you've already been given advice to implement a VBD.