My lab recently purchased the BIOPAC system to measure skin conductance as part of our experiments.
My experiments are normally coded using Livecode.
I need to be able to tell Livecode to automatically score and label digital event marks in the skin conductance responses in the BIOPAC System.
Does anyone have any experience interfacing the BIOPAC system and Livecode? Does anyone have same code they have used?
Thanks!
There is a gadget from "Bonig und KallenBach":
http://www.bkohg.com/serviceusbplus_e.html
This has analog inputs that you could easily configure to measure skin resistance. It comes with a framework for LiveCode, and connects through the USB port.
I have used these in many applications to connect the real world to my computer. All your processing is done in the usual LC way.
I think, there is no direct Example using Biopac Hardware.
To tinkering with your own software outside AcqKnowledge, you have to purchase BHAPI (MPDEV.dll) from Biopac. The problem is BHAPI only support Windows. not MacOS nor Linux.
Another way is streaming data through AcqKnowledge 5.x. Start acquisition in AcqKnowledge, and you can stream it. Then receive the data stream in livecode and process it.
I have a board on my Watson IoT dashboard, which I use to monitor temperature real-time with a line graphic.
I have a second dashboard with a different organisation, and I want to import the graphic which is in the board in the first dashboard, without making again the same graphic.
I've already tried that solution and, even if possibile, it wouldn't be efficent. I mean, I already have the data on IoT why sending from IoT to Iot?
So, can i display on, let's call it... dashboard2, the board with the temperature (or any other property) which is in dashboard1 without sending or duplicate data on dashboard2?
If so, how can i do that? It's almost a week that I'm searching, and I start to doubt that something like this actually exists...
I´m going to create a web service for learning purposes and wanted to combine it with my WoW Hobby. My goal would be to create a "simple" Addon, which tracks my battleground activity in real time.
So when queuing for AB it enters my data in an db and when I´m out of the BG it should delete the db entry. The information should be stored in an JSON/XML-File and whenever the bg-status changes it should execute the post/update on the DB on the RESTful service.
The real time communication is very important here and I would like to know which ways of communicating to a web service are available, so I could directly dive in and create a solution.I´d like to have resources instead of solutions.
Currently I´m not used to LUA, but would like to learn it to get the knowledge of creating such a service.Which sites are you suggesting for learning LUA, especially the WoW-API?
Addons only write to disk when you log out of a character (and read that saved data when you log in) so what you intend would not be possible.*
More involved ways of communicating with the rest of the computer or even the internet are prohibited to prevent the gain of certain advantages, an example would be looking up details about your Arena opponents.
* Well, there are certainly some ways, but rather complicated ones: a program monitoring sound output to check when the BG queue pop sound is played, or a screengrabber that registers when the BG score screen comes up (which can be viewed during the match though, too)
I am trying to connect two Arduino Yun boards to each other via WIFI (make one board control a pin on the other board an vice versa) and I am having trouble making it work the way I want to.
This is where I've gotten so far:
I have two Arduino Yun boards with a simple sketch installed on each, which works fine as long as I keep the "connecting-each-other"-part out of it. It uses a potentiometer on the analog port, reads its value, maps it to the range of 0-255 an fades a LED up or down on one of the digital pins (brighter / darker) depending on the given value. Now I want to use the potentionmeter of one board to control the LED on the OTHER board.
To do that, I tried to use the REST API. I combined my sketch with the code from the "Bridge" Example Sketch, which sets up a http-client/server on the Arduino Yun (on the Linux part) allowing it to receive requests to control and read patricular pins via http.
When using the specific URL for the REST API in a browser, it works fine. For example: when I type "http://myarduino.local/arduino/digital/3/1" it sets the value of digital pin 3 to 1 (i.e. LED is switched on) --> so that's all fine
I am not sure how to continue at this point, since I dont want to control the board from a browser or app but make one Arduino Yun control another Arduino Yun directly. If I put a http request in my sketch like mentioned above via client.get and client.read (as in the example sketch) it does not work. See example code below. It doesnt have any effect nor does anything appear in the serial monitor (with the original URL "http://arduino.cc/asciilogo.txt" like in the example, the ascii code appears in the serial monitor)
HttpClient webclient;
webclient.get("http://ardu1.local/digital/3/1");
while (webclient.available()) {
char c = webclient.read();
Serial.print(c);
}
Serial.flush();
I am a beginner with Arduino Yun boards and maybe I am missing something?
Thanks for any help or pointing me in the right direction. Or if you need more information to help me with this problem, please let me know.
I found another way to connect two Arduino Yun boards directly, or as close to "directly" as it probably gets. The REST API was not the right way to go. So this is for anyone who might encounter the same "problem":
After some research I came across "Spacebrew". It's based on "websockets" and requires a server to connect the boards to each other, but it is very flexible. It's also fairly easy to setup a spacebrew server locally. It allows every client (like a Arduino Yun board) connected to the server to publish different types of data (boolean, range, value) and/or to subscribe to the published data from other devices using a simple webinterface. The good thing is, that the connection is fast and there's no waiting for the connection to be reestablished when there is data to be sent.
I used the Arduino Example Sketch "spacebrewRange" and it worked fine for me.
It also requires a few other things before it can work, but its explained on the website and in a tutorial:
http://docs.spacebrew.cc/gettingstarted/
http://de.slideshare.net/julioterra/spacebrew-server-workshop-itp
Trying to do the same, it seems, and for me it works (this bit at least :-|
I let one arduino request the URL "http://router.domain:port/arduino/key/value", using a Process which runs cURL. The receiving arduino interprets this request to set the key to the value, using a YunClient.
From the URLs in your question, it seems that you are missing the mandatory "/arduino/" component in the path name. As far as I know, this is needed to direct any requests directed at the OpenWRT stack to the arduino/Leonardo part.
I have developed a software piece (with C and Python) which I want to protect with dongle so that copying and reverse engineering becomes hard enough. My dongle device comes with an api which provides these:
Check dongle existence
Check proper dongle
Write into a memory location in dongle
Read from a memory location in dongle etc. (I think the rests aren't that good..)
What I can do in the source code so that it becomes harder to crack. Dongle provider suggested that, I should check proper dongle existence in a loop or after an event, or I should use the dongle memory in an efficient way. But how? I have no idea how crackers crack. Please shed some light. Thanks in advance.
P.S: Please don't suggest obfuscating. I have already done that.
First of all, realize that the dongle will only provide a little bit of an obstacle. Someone who knows what they're doing will just remove the call to the dongle and put in a 'true' for whatever result that was called. Everyone will tell you this. But there are roadblocks you can add!
I would find a key portion of your code, something that's difficult or hard to know, something that requires domain knowledge. Then put that knowledge onto the key. One example of this would be shader routines. Shader routines are text files that are sent to a graphics card to achieve particular effects; a very simple brightness/contrast filter would take less than 500 characters to implement, and you can store that in the user space on most dongles. Then you put that information on the key, and only use information from the key in order to show images. That way, if someone tries to just simply remove your dongle, all the images in your program will be blacked out. It would take someone either having a copy of your program, grabbing the text file from the key, and then modifying your program to include that text file, and then knowing that that particular file will be the 'right' way to display images. Particulars of implementation depend on your deployment platform. If you're running a program in WPF, for instance, you might be able to store a directx routine onto your key, and then load that routine from the key and apply the effect to all the images in your app. The cracker then has to be able to intercept that directx routine and apply it properly.
Another possibility is to use the key's random number generation routines to develop UIDs. As soon as someone removes the dongle functionality, all generated UIDs will be zeroed.
The best thing to do, though, is to put a domain specific function onto the dongle (such as the entire UID generation routine). Different manufacturers will have different capabilities in this regard.
How much of a roadblock will these clevernesses get you? Realistically, it depends on the popularity of your program. The more popular your program, the more likely someone will want to crack it, and will devote their time to doing so. In that scenario, you might have a few days if you're particularly good at dongle coding. If your program is not that popular (only a few hundred customers, say), then just the presence of a dongle could be deterrent enough without having to do anything clever.
Crackers will crack by sniffing the traffic between your app and the dongle and either disabling any code that tests for dongle presence or writing code to emulate the dongle (e.g. by replaying recorded traffic), whichever looks easier.
Obfuscation of the testing code, and many scattered pieces of code that perform tests in different ways, as well as separating spatially and temporally the effect of the test (disabling/degrading functionality, displaying a warning etc.) from the test itself make the former method harder.
Mutating the content of the dongle with each test based on some random nonce created each run or possibly even preserved between runs, so that naively recording and replaying the traffic does not work, will make the latter method harder.
However, with the system as described, it is still straightforward to emulate the dongle, so sooner or later someone will do it.
If you have the ability to execute code inside the dongle, you could move code that performs functions critical to your application there, which would mean that the crackers must either rederive the code or break the dongle's physical security - a much more expensive proposal (though still feasible; realise that there is no such thing as perfect security).
How to maximize protection with a simple dongle?
Use API together with Enveloper if an enveloper exists for your resulting file format. This is a very basic rule. Because our enveloper is already equipped with some anti-debugging and obfuscating methods to prevent common newbie hackers to give up hacking the program. Only using enveloper is also not recommended, because once a hacker can break the enveloper protection in other program, they can also break yours.
Call dongle APIs in a LOT of places in your application. For example when first start up, when opening a file, when a dialog box opens, and before processing any information. Also maybe do some random checking even when there's nothing done at all.
Use more than one function to protect a program. Do not just only use find function to look for a plugged dongle.
Use multiple dlls/libraries (if applicable) to call dongle functions. In case one dll is hacked, then there are still other parts of the software that uses the functions from another dll. For example, copying sdx.dll to print.dll, open.dll, and other names, then define the function calls from each dll with different names.
If you use a dll file to call dongle functions, bind it together with the executable. There are quite some programs capable of doing this; for example PEBundle. 3
I have got this article on PRLOG and found it quite useful on maximizing protection with a simple dongle. Maybe this link may help you
Maximizing Protection with a Simple Dongle for your Software
You can implement many check points in your application.
I don't know if you use HASP, but unfortunatelly, dongles can be emulated.
You may want to look into using Dinkey Dongles for your copy protection.
It seems a very secure system and the documentation gives you tips for improving your overall security using the system.
http://www.microcosm.co.uk/dongles.php
Ironically, the thing you want to discourage is not piracy by users, but theft by vendors. The internet has become such a lawless place that vendors can steal and resell your software at will. You have legal recourse in some cases, and not in others.
Nothing is fool-proof, as previously stated. Also, the more complex your security is, the more likely it is to cause headaches or problems for legitimate users.
I'd say the most secure application is always the one tied closest to the server. Sadly, then users worry about it being spyware.
If you make a lot of different calls to your dongle, then maybe the cracker will just emulate your dongle -- or find a single point of failure (quite common to change one or two bytes and all your calls are useless). It is a no-win situation.
As the author of PECompact, I always tell customers that they can not rely on anything to protect their software -- as it can and will be cracked if a dedicated cracker goes after it. The harder you make it, the more of a challenge (fun) it is to them.
I personally use very minimal protection techniques on my software, knowing these facts.
Use smartcard + encrypt/decrypt working files through secret function stored in card. Then software can be pirated, but it will not able to open properly encrypted working files.
I would say that if someone wants to crack your software protection, they will do so. When you say 'hard enough' - how should 'enough' be interpreted?
A dongle will perhaps prevent your average user from copying your software - so in that sense it is already 'enough'. But anyone who feels the need and is able to circumvent the dongle will likely be able to get past any other scheme that you engineer.