I read through it and concluded it was too complicated: the minimum requirement set is too large, and the event protocol is poorly organised, with little provision for a simple API with message reuse.
I'm open to second opinions, though!
Actually I respect the work of others and think that in general they took some decision in base to constraints. I´m not read the entire protocol and see that it´s not wide extending but I haven´t any reason to think that we can do something better working from the scratch if we not discuss first EXACTLY what are the use and boundary of our sub-protocol.
You propose a series of datagrams species, but what is the scenario? Which are the limits to our design? Which is the general philosophy? What are the physical problems that we need to solve in practice? Connectors, wiring and pin out is only a small part of real word problematic.
To this point, reading the previous post I think that we are plan to working in a multi-master, long wire (more than 20 meters), event based protocol that must minimize the controller software footprint (please, correct me if this is not accurate).
In resume, the same that I ask from the beginning, exactly what kind of data we are moving in this protocol and which are their clear limits? It´s impossible to plan a protocol that works in every scenario with every data type and serves all the purposes. I think that I share in thick line the objectives with folknology, but what about the others?
I think that magetoo propouse use the other pair of the RJ-45 to power device, not the same wires. A friend need to use one RJ45 for ethernet, 12 volt and CAN and all work OK for three years. It´s dirty, but works.
I think that when we have a first network working we can see some points that underestimated and other that not.
At this point it´s possible that and intelligent switch would be a very clever solution and his cost wouldn´t a problem. In my particular case with an intelligent repeater I can replace a hub or a switch because I have a lot of traffic that it´s only interesting to a stub or sub net of nodes and can be filter to the primary bus. With a ucontroller with two can ports I can use the filters in the stack to determine message forwarding. This is clean, simple and relatively cheap in cost and software. But I not know that this is appropriate in general.
About the interlock or deadlock of the first link it´s true. When I see this and the user in the forum (and others) said that works I think that would be to good to be true. Perhaps at low speed or with a fault tolerant schema it works, but I put the second link because this silicon has the logic to act as repeater without uController.
I search a bit more and this Application note http://www.onsemi.com/pub_link/Collateral/AND8358-D.PDF explain about the feedback suppression logic and shown a simplified circuit that may be work. Off course FBS block is the key to avoid interlocking but perhaps with some digging we can develop something. Onsemi circuit cost aprox $4 and I think that it´s OK in cost if permit to me simplified a wiring schema were not only the wire cost itself would be relevant but installation it´s more expensive.
I'm wondering if instead we can find or devise a simpler protocol along similar lines. For instance, instead of a thousand different message types, we can define just a few, and each event can specify which message type it uses. There's a lot of overlap in message content in VSCP, but no attempt to combine them into coherent message types.
I agree! I think that VCSP can be use as start point and use the better for us. Indeed I not see that the message collection of VSCP was too complex to implement, but the better way it´s agree here our needs.
And this two posible solutions that I found in forums. I confess that first option sound to good to be true and is simple to explore. I need to finish other project and then start t test a "naif repeater" like this :-)
I´m read this morning part of the specification, seems to good to be true. I´m continue this night and not read the software section, but I think that eventually we need to "recode" the clients and perhaps reuse as is the PC side (if it´s necessary) because all have a PC and resources never are a bottleneck. I can´t see any more but if it´s not the goal that we need it´s a very complete source of experience.
I think that if you need only a couple of CAN to Ethernet bridge it´s better buy something done, if you need more then it´s better make the entire solution. It´s cheaper and more control on changes and features.
Hi, I remember to see this logo few years ago but actually not see nothing relevant. But that was long time ago.
I need to read the current specification, may be very sefull or becomes a start point to something else, but at first sight:
* I usually distrust about the same protocol in very different transport. Each transport has their advantages and his drawbacks. A lot of this was written at beginning of this post. It´s hard to believe that it´s efficient a transport protocol that works at same time in RS232 and ethernet. Off course, always it´s use full a bridge to transport the signal to a long distance or to a mobile device, because in rare certain circumstances port the same protocol in different transport it´s use full. VCSP may have a point here.
* I prefer allways to take advantage of a STACK hardware. I can do Ethernet bit banging but it´s a nonsense out of an academic campus. If VCSP uses CAN Stack and then work with all of this advantages (and drawbacks sadly) but, for example, port the same data stream to a RS485 network and use all the pros and cons, then would be a MARVELOUS SOLUTION!
In resume, if Folknology can implement their devices in RS485 network with all of the advantages that he write few days ago using VCSP as compatible data transport, and I can use CAN Stack with filtering, addressing and noise immunity to manage my sensors and we can put a ""silly bridge"" that translates from one electric wire to other to join both networks then I´m IN without doubt!. :-)
Yes, I can agree with both in other cases when the final product isn´t an analyzer or a measure instrument.
In the practice sometimes Linux (or windows, not apologies here!) it´s a swamp. In the chain of tools sometimes fail the driver, sometimes crash the operative system, sometimes an angel cry and all work ends in the trash bin. Even I don´t know if in the next year when I need other "CAN Analyzer" (because I lost mine board or toast it for sure!) I can buy an exact RPi ver. B or a BeagleBoard like this design uses and then begin´s with hardware tweaking and software adaptations.
I not say to do the graphic client in an LCD or something similar in the Cortex ucontroller (it´s possible but I need to start from scratch and is silly) but use the ucontroller as a smart interface (perhaps with a SD memory card) and read the commands from something (Rpi, Beagle, tablet, PC, Phone, etc.) connected to an ethernet port as a file or a data stream ( a lot of well know tools do this) or format the output as HTML code and show it in a web side that act as fast front end. Then if I prefer use it from a tablet or smartphone in the field or from a desktop PC in the laboratory and all works ok. I can use the OS to implement a client, but it only interpret a result in a standard port, not implements a bitbanging CAN library or a specialized hardware. Sorry, I fall in this trap a lot of times in my life and prefer not fall again.
Recently I have a similar situation with OLS from this site. The FPGA Code its a Jewell of Work! It´s left behind a lot of other LA and with some signal conditioning works even better than my old HP Logic Analyzer, but, the interface between core and PC was done with a "slow" USART port with a "slow" controller and for completeness uses JAVA for the client with not very reliable serial drivers. Work? YES, OFF COURSE! It´s a wonder full piece of technology; but Murphy Laws are mandatory and Java client hang up in my worst day, losing the entire data and in some times trying lot of time to communicate. I need to go with my big notebook to a site when a small tablet do his best work.
For justice 90% of time it works like a charm, but in a reliable tool we need almost 99.5% of time. Even when work OK took a "lot of time" download long captures to the client. Somebody says that this LA it´s a toy, but I thing that somebody do a excellent work in the Core and somebody do an excellent work in the client and OLS can be a lot more than a toy. I recommend it for all my friends and we are almost happy but some disappointing. If the people at design time spend 5 more dollars (10% + of final cost) they can use a powerfull processor plenty of memory and power to manage alternatives at the original SUMP protocol and now somebody can try a different approach in the same board. Can I build my own OLS? Yes, off course in the near future but today I continues using my HP in the field.
For all of this prefer a "smart" box that I can use as CAN logger and use something else to read the data an configure the logger.
At hardware level I probably run CAN Analizer from a ST microcontroller connectivity line and establish a bridge between CAN and USB or Ethernet (via web service for use with any client). I not see the advantage of using a complex operative system or a powerfull board like RPi. CAN run in processors of low power, at max protocol speed we are in less than 200KByte second. Almost all the ARM Cortex that I use permit DMA between stack buffers or format text around the CAN stack and redirect it at more high rates than 200Kbyte.
But let´s go with the solution that you are more comfortable and I adapt the C code to my hardware implementation, its the beauty of open solution :-).
At initial planning we use RJ45 but the cost escalate high for the long distances. Even inside the greenhouse the wiring run in long distance.
Instead of this we are planning to use thicker central wire at top of greenhouse and divide near the devices with 2 pair RJ11 to devices with low current budget.
At this point we are very interested in check how long can be the stub if we use linear bus. Optimally the stubs must be less than 50 cm but in laboratory we can made a central network with 3 stubs of 10 meters and not suffer to much data stress or loss packet but the max velocity not exceed 125 Kb.
If we can go with a central line and relatively long stubs the wiring is less expensive.
Simplest solenoids (less than 6watt) , controllers and sensors use low current and can be connected to low current wires in RJ11. Motors and actuators would be connected to AC main or to the thicker wires, not to the "low current wires".
One option it´s use RJ45 connector in the PCB, send the data lines at center and put power at sides. If you need low current uses a Rj11 connected at center of Rj45 (2 data and 2 power wires) or uses a full RJ45 with 4 pair and obtain 1 pair to data and 3 pair for power. Same connector but two options, and PCB RJ45 cost is very similar or equal to RJ11.
We are working with 24 volts but allow 20 to 36 volt, essentially all the devices uses switching DC-DC power supply to adjust to 12, 5 or 3.3 volt in each case.
In the real world the cost of sensor and controllers is the less expensive. Wires, IP67 Boxes, connectors and power supplies cost 10 times the cost of Controller PCB, Sensors, and 4 relay in each greenhouse!
Almost in Argentina, display, knobs, connectors and box used to be more expensive than the electronic inside. It´s by far less expensive program a interface WEB-CAN and control all the network from a cheap chinese android tablet than construct display panels, keyboards and indicators.