Firstly I am new to this and I have tried googling for answer but figured it is best ask the experts.
There is a building management system (BMS) that is using BACnet protocol but my equipment logger only has Modbus TCP/IP. I understand that the market has a converter for this but I will like to know the concept.
Modbus TCP/IP has registry values (e.g 40135) which is dedicated to a specific parameter reading. How does the converter read this registry value in the BACnet BMS? Do you have to specific this registry value in the converter software for the output at BACnet?
In general, what should be input at the BACnet end to read the equipment parameter such as power received?
In this situation, is the BACnet BMS consider the MASTER and the equipment as SLAVE?
I hope someone can take some time to clear my doubts on this. Will really appreciate it.
Thank you.
A couple of assumptions on my end regarding the setup:
Your equipment is acting as a "Modbus/TCP Slave" (i.e. it will respond to
polls from a Modbus/TCP Master)
The converter then acts as a Modbus/TCP Master
And then the converter acts as a BACnet slave/server (or in BACnet terminology, a "B" device)
And your BMS system polls the converter as a BACnet master/client/"A" device
That is the normal setup. Then the converter device has the responsiblity to poll your equipment for the value from the Modbus register, and this is normally only a 16 bit integer, or in some cases, vendors pack a float into two 16 bit integers using a variety of byte-order and floating point formats. It is a mess. Nevertheless, the converter, if is a good one, will allow you to unpack the value into a float, and provision it with some BACnet specific metadata ("Properties") such as Units, BACnet Object Type, Object Instance, Reliability flags etc. etc. and make this new object discoverable by any BMS system.
More sophisticated converters can add other BACnet services, such as Change-of-Value (COV), Intrinsic Alarming, Trend Logging if desired. This is of course, dependent on the particular vendor.
Just to add to what's already been said; a lot of the time - out in the field, there are gateway devices, that encompass the conversion process for you, so unless you're the one setting-up the BMS, you generally don't have to concern yourself with the conversion specifics.
If the device's 'Max(imum) ADPU Length' is set to 480, then the device is probably a Modbus device (/a Modbus device is probably sitting behind the gateway's/converter's (object) point.
Related
I want to implement a P2P protocol in C for personal education purposes.
What would be the protocol with the shortest specification that is still used today?
I have already implemented a web and IRC client and server.
I agree with Mark, that point to point over a serial link would be a good exercise.
In particular, I would recommend the following programme of stuff...
Implement basic transmission over a "Serial Port" (using RS-232 if you have some Arduinos/embedded processors lying around, or using a null modem emulator if you don't (see com0com on Windows, or this on linux/mac).
I.e. send lower case letters from A->B, and echo them back as upper case from B->A
Implement SLIP as a way to reliably frame messages
i.e. you can send any string (e.g. "hello") and it is returned in upper case with "WORLD" appended ("HELLOWORLD").
Implement the "Read Multiple Holding Registers" and "Write Multiple Holding Registers" part of the Modbus protocol, using SLIP to frame the messages.
I.e. you have one follower (slave) device, and one leader (master) device. The follower has 10 bytes of memory that are exposed over modbus with the initial value "helloworld".
Just hard-code the follower / leader device Ids for now.
The leader reads the value, and then sets it to be "worldhello".
At the end of this you would start to have an understanding of the roles of network layers, ie:
The physical layer - Serial/RS-232
A "link layer" of sorts - SLIP
An "application" layer - Modbus
Serial. The answer is serial. You're not going to get any leaner than simple RX/TX communication but you'll lack a lot of convenience methods. If you want to explore more than simple bidirectional comms, I2C or modbus open up a lot of options.
I'm dealing with the following challenge. In my system, there are two devices. Tags and anchors. Tags have BLE module with the transmit power 0dBm and not Long Range feature (BLE 4.0). Anchors have BLE module with transmit power over 8dBm and Long range feature (BLE 5.0).
I want tags to only receive some commands. Bi-directional communication is not necessary. This way, I can utilize the transmit power of anchor (8dBm) and thus quite bigger range, if tag with 0dBm is only receiving.
I read something about Observer/Broadcaster principle, where connecting is not necessary. But somehow devices have to agree on what frequencies should they hop on, the step and so on.
I'm asking, is it possible for device to only receive commands without previous negotiation with the sender?
Thank you very much for help. I'm beginning with BLE standard and there is a lot to learn.
Yes, it is possible to send data via adverts/scanning only. This way, there's no connection that needs to be established, and therefore no connection parameter negotiation takes place. As for the frequency hopping agreement - this happens via the baseband (in other words you will not deal with this in the software yourself) and is generally not applicable for advertising/scanning (these happen on 3 frequency channels only and therefore it is likely that the observer will catch what the broadcaster is broadcasting).
However, keep in mind that because you are broadcasting/advertising the data as opposed to directly sending it, that data can be received by any observing/scanning BLE devices which is not desired for safety/security/privacy purposes.
For more information on BLE communication, I recommend the links below:-
Getting Started with Bluetooth Low Energy
Is it Possible to Send Data with BLE Broadcast Mode
I'm building a linux-based cashless device and trying to achieve communication with VMC in vending machines over UART directly without needing additional hardware adapter to convert between 8-bit and 9-bit frame data.
I'm only using the cashless device, no intention to connect any other peripheral to the VMC.
I read questions asked about this before, some of them stressed on the need to an adapter, others suggested possible hacks to achieve the 9-bit to 8-bit conversion, but still can't find a confirmed working and stable solution.
My question is, Is it possible (and reliable) to achieve this using a pure software solution? and how?
Thanks
Yes.
The 9th bit is a control bit. It will show if the data is to be interpreted as an address or as data. If you are communicating with one device and sending only data you want to strip the 9th bit out and only look at data frames. Check and see if it's always zero:
If controlBit = 0:
ProcessData(byte)
Else:
print("This is an address: " + byte)
EDIT:
Many people have reported that your connection will not be stable without special hardware due to timing problems.
Instead of reinventing the wheel you can use opensource code as a starting point.
https://github.com/mhaqs/vendiverse/wiki/Programming-the-VMC
This way you don't have to make the same mistakes over and over again.
I am currently working on a project which aim to detect Bluetooth and decode Bluetooth packets (I use a Hack RF One to make the detection). I have made a Gnuradio Flowgraph in order to demodulate Bluetooth signal and I am trying to decode visualy the packets by searching a Bluetooth frame on a binary file.
Unfortunately, I didn't succeed to recover a clear view of the Bluetooth signal. To be precise, I am pretty sure that I detect Bluetooth on my sinks but when sending this to a Clock Recovery + Binary Slicer blocks, I am unable to recover interresting data in the binary file (especially the MAC adress of the sending device, which is part of the a Bluetooth packet). Moreover, I would like to know what type of network layer (physical, transport, baseband...) is intercepted in this type of process. In my case, I aim to intercept baseband layer packets.
Additionaly, I am interrested in knowing how to use the gr-bluetooth because I can't find a lot of documentation concerning this block. I think this can be interresting for the development of my project.
Could you please, give me your view, opinion about this problem ? I am stucked at this stage without knowing the exact origin of my issue. (Here is my flowgraph GnuRadio_Flowgraph and a screenshot of one of my Bluetooth detection Detected signal at 2.402GHz).
Thank you very much,
You probably need an ubertooth instead https://www.sparkfun.com/products/10573
I read that the bluetooth frequency skipping is spread wider than the HackRF can read, so at-best, you're going to miss 75% of frames if you only have one hackrf connected.
I have a device that takes low current 3-12v input signal to do it's magic and I would like to interface it to my linux box. What kind of options do I have on this? It would be great to have some low-cost possibly user-space solution.
If I understand right, you need to control your box by changing 3-12v input signals to it. Here's the choices I can think of from the top of my head:-
a: Using RS232 serial handshake lines. RTS/CTS can usually controlled programatically as "on/off" signals without driver development using IOCTL calls.
b: Use a "GPI dongle" such as the Advantech ADAM range. These typically take serial or TCP/IP inputs and convert them to suitable output signals.
c: You may be able to do something with a parallel printer port if your PC stil has such a thing.
As shodanex says, be aware that RS232 levels are NOT directly compatible with TTL/CMOS inputs so you may need some minor level shifting/clamping electronics to fix this.