I’m doing a project where I need to send some data between to devices with a RFM12B transceiver. I’m using the RF12-library with the pingPong example – nothing is modified.
My microcontroller is ATTiny84A and the wiring can be seen HERE
My problem is that it simply doesn’t work. The initialize seems to work. The first few seconds rf12_canSend() also returns true, but after that it returns false. My guess is that it starts to send some data but for some reason it can’t. I have no clue about what the problem is but my only guess would be that it isn’t using the right pins but I’ve followed the example.
Ignore the LED, it’s for testing.
Related
I have the project to develop an application that would allow a computer to 'send' a window to another computer.
In order to do that, I need, of course, to capture the concerned window's output from my program.
Google searches leaded me to no relevant result, neither with libX11 nor libxcb.
I also tried to record screenshots with xwd and import, but as they are quite slow, I'm getting up to 3.5 fps
Any help on how I could do that will be welcome (either using libX11, libxcb, or something else)
By the way, I attempt to use c++ for this program
Thanks for reading,
Edit:
The fps test was made without sending files. It was just like "I took screenshots for 5 minutes, and I got 900 pictures"
I think you will need to record screenshots and compress them before sending over network to make things faster. Also, you would need to decrease the quality of the screenshots (user configurable) to make it faster.
Plus there are different techniques to send only the changes (diff of screenshots) to the other computer.
Well, three questions in less then 24 hours.But I suppose the lack of any helpful documentation (that i can find anyway) gives me no choice.
now i know all about the security stuff adobes got going, the policy file deal and sandbox limitations that have to be juggled around. ive done the suggested options changes, allowing network access in my AS3 project. I got my server ready to spit the policy file out instantly upon connection; but the problem is flash/AS3 whatever you wanna call it simply doesn't see my server (or the other way around)
AS3 delays for a few seconds, like the documentation say it will if its struggling to make a connection/find the policy file, but it never makes a connection period, tries for a while and then gives up and spits me a access error (because it didn't find the policy file it assumes its not allowed on the network so it get mad at me for trying... lil stubborn buggers)
Flash never gets what its looking for, and my server never detects any connections (failed or succeeded, nothing) I know my server is good because i've tested it with a test client i wrote in C++ and they talk just like best friends.
So I'm pretty much and a loss for ideas now, I thought about re-creating the winsock classes in AS3, but i don't even know how the connect() function fro winsock actually works; i got the declaration, no definition for it that i can find.
I am not sure what you would really need from my source code, but there's over a thousand lines in the client alone already so posting it all isn't really an option. ill give here what i think is relevant at least.
function hwndEnterFrame(e:Event):void
{
//trace("Frame Entered");
if (firstframe)
{
trace("try to reconcile policy file...");
//Security.loadPolicyFile("192.168.1.2:843");
TSocket = new Socket("192.168.1.2",843);//must call flush() to send data***
firstframe = false;
}
The Security.loadpolicyfile doesnt seem to do anything as far ive noticed, i get the same msgs with or without it, the code seems to be looking for the policy file at the location specified in the socket declaration. Everything compiles fine, it just ain't doing what i want it do :P everyone else seems to be writing their servers in Perl or Python i haven't found much of an abundance of C++ material, although from what i understand TCP is a universal connection across any platform that supports it (can cross-language without any funny-business)
meh, that what i got for now, if you want other parts of the code (client or sever side, whatever you want) ill stick it up here quick-like.
EDIT:
I found a swf online that i downloaded, it connected fine to the example server that came with it (but that server was written in c sparp so its not much use to me) but it wont connect to my server. So a known good flash client WONT connect to my C++ server, but a C++ client WILL connect to my C++ server. So its clearly somthing on the server side, becuase it dosnt hear any connection whatsoever from the flash apps (mine or the expamle one)
Cheers;
-Tyler
I finally figured it out. I needed to AllowDomian(IPofserver). I thought I had already tried that but apparently not.
Sometimes (in about 50% of runs), EnumDevices takes 5-10 seconds to return. Normally it is almost instant. I couldn't find any other reports of this kind of behaviour.
When things are this slow, it's ok to profile by watching stdout :) This:
std::cout << "A";
directInput8Interface->EnumDevices(DI8DEVCLASS_GAMECTRL, MyCallback, NULL, DIEDFL_ATTACHEDONLY);
std::cout << "C";
...
BOOL CALLBACK MyCallback(LPCDIDEVICEINSTANCE, LPVOID)
{
std::cout << "B";
return DIENUM_CONTINUE;
}
Seems to hang at a random point through enumerating devices - sometimes it'll be before the callback is called at all, sometimes after a couple, and sometimes it will be after the last call to it.
This is clearly a simplified chunk of code; I'm actually using the OIS input library ( http://sourceforge.net/projects/wgois/ ), so for context, please see the full source here:
http://wgois.svn.sourceforge.net/viewvc/wgois/ois/trunk/src/win32/Win32InputManager.cpp?revision=39&view=markup
There doesn't seem to be anything particularly fruity going on there though, but possibly something in their initialisation could be the cause - I don't know enough about DI8 to spot it.
Any ideas about why it could be so slow will be greatly appreciated!
EDIT:
I've managed to catch the hang in an etl trace file and analysed it in Windows Performance Analyzer. It looks like EnumDevices eventually calls through to DInput8.dll!fGetProductStringFromDevice, which calls HIDUSB.SYS!HumCallUSB, which calls KeWaitForSingleObject and waits. 9 times out of 10 (literally - there are 10 samples in the trace) this returns very quickly (324us each), with the readying callstack containing usbport.sys!USBPORT_Core_iCompleteDoneTransfer followed by HIDUSB.SYS!HumCallUsbComplete, which looks quite normal.
But 1 time in 10, this takes almost exactly 5 seconds to return. On the readying callstack is ntkrnlmp.exe!KiTimerExpiration instead of the HIDUSB.SYS function. I guess all this indicates that the HIDUSB.SYS driver is querying devices asynchronously with a timeout of 5 seconds, and sometimes it fails and hits this timeout.
I don't know whether this failure is associated with any one device in particular (I do have a few USB HIDs) or if it's random - it's hard to test because it doesn't always happen. Again, any information anyone can give me will be appreciated, though I don't hold out any hope for Microsoft fixing this any time soon given the odd situation DirectInput is in!
Perhaps I'll just have to start initialising input earlier, asynchronously, and accept that sometimes there'll be a 5 second delay before user input can happen.
I was running into this too, largely as an end user, but it's been annoying the hell out of me for years. I didn't realize it was this issue until I ran into it on an open source project and was able to debug it.
Turns out it was my USB Headphone DAC (The Objective DAC from Massdrop), it installs the driver: wdma_usb.inf_amd64_134cb113911feba4\wdma_usb.inf for Device Instance ID USB\VID_262A&PID_1048&MI_01\7&F217D4F&0&0001 and then shows up in Device Manager under Sound, video and game controllers as: ODAC-revB USB DAC and, under Human Interface Devices as: USB Input Device and HID-compliant consumer control device.
I have no idea what the HID entries do but... When they are enabled and this DAC is set as the Audio Output device both IDirectInput8_CreateDevice and EnumDevices are painfully slow. Disabling the "USB Input Device" entry seems to cause no negative effects and completely solves my issue.
Changing the Audio output from the DAC to anything else also weirdly solved the issue.
This was so bad that it made the Gamepad Configuration dialog joy.cpl unusable, hanging and eventually crashing.
I was wanting this to just be a comment but I don't have enough rep for it, and this is pretty much the only place on the internet that describes this problem though so hopefully this helps someone else one day!
I had the same issue. I have a Corsair K65 LUX RGB keyboard. I updated CUE and it seems to have fixed the issue
Got same issue when having my Corsair K55 Keyboard. Changing the keyboard of USB port fixes the issue for a while, but then it comes back later on. So it seems to be a buggy drivers issue.
As DaFox has pointed out, a likely cause appears to be certain device drivers being enabled. I contacted JDS Labs support (who sell one device which happens to install one such driver) and they kindly pointed out that the root cause is actually a bug within Windows (not the installed driver), and they actually provide the solution on their troubleshooting page. See Games hang or experience loading delays, which explicitly mentions VID_262. Disabling this driver fixes the issue without apparent side effects (under the condition that that is the only driver triggering the bug). As for what exactly is going wrong within Windows, here there be dragons.
So I guess the go-to solution (for users) is to scrape all the troubleshooting and FAQ pages for all devices which you have ever connected to your system and see if there is a mention of delays/lag caused by a driver.
As a software developer, you will probably want to benchmark the execution time of the affected code and kindly tell the user there is something wrong with their system configuration and where to look for how to fix it in case it is unreasonably long.
Same issue with Corsair K70 Keyboard.
Quickly reconnecting keyboard fixes this, until next time. Usually happens after some DirectInput devices removed from the system or go to sleep.
This has been plaguing me as a developer and my friend as a user for years. All games using DInput, SDL SDL_INIT_JOYSTICK or anything depending on that, took extremely long to initialize.
It was caused by a faulty driver of a DAC, and as pointed out by DaFox, disabling the corresponding USB Input Device resolved the issue. Although it's labeled with a different manufacturer name, the vendor IDs match.
The hardware ID of the device is USB\VID_262A&PID_9023&REV_0001&MI_00.
Same issue appears to happen with a Steelseries Apex 7 keyboard. Unplugging and plugging that keyboard back again got rid of 3 freezes (of 10 seconds each) while enumerating USB devices.
The overall program is too complex to display here. Basically, just pay attention to the green highlights in my recent git commit. I am very new to DirectInput, so I expect I've made several errors. I have very carefully studied the MSDN documentation, so I promise I'm not just throwing this out there and stamping FIX IT FOR ME on it. :)
Basically, I think I have narrowed down my problem to the area of code around Engine::getEvent (line 238+). I do not understand how these functions work, and I've messed with certain pieces to achieve different results. My goal here is to simply read in keyboard events directly and output those raw numbers to the screen (I will deal with the numbers' meaning later). The problem here relates to KEYBOARD_BUFFER_SIZE. If I make it small, the program seems to run fine, but it outputs no events. If I make it big, it runs a bit better, but it starts to slow down and then freeze (the OpenGL window just has a rotating color cube). How do I properly capture keyboard events?
I checked the return values on all the setup steps higher in the code. They all return DI_OK just fine.
Your code seems to be okay (according to this tutorial, which I have used in the past). The use of several stack-based arrays is questionable, but shouldn't be too much of an issue (unless you start having lots of concurrent getEvent calls running).
However, your best bet would be to stop using DirectInput and start using Windows Raw Input. It's best to make this switch early (ie, now) rather than realise later on that you really need to use something other than DI to get the results you want.
I have got the following situation. On a machine there is a Fritz ISDN card. There is a process that is responsible for playing a certain wave file on this device's wave out (ISDN connection is made at startup and made persistent). The scenario is easy, whenever needed the process calls waveOutWrite() on the previously opened wave device (everything initialized without any problems of course) and a callback function waits for MM_WOM_DONE msg to know that the playback has been finished.
Since a few days however (nothing changed neither in the process nor the machine) the MM_WOM_DONE message has been coming immediately after calling waveOutWrite() even though the wave lasts a couple of seconds. Again no error is reported, it looks like the file was played but had zero length (which is not the case). I am also sure that waveOutReset() was not called by my process (it would also trigger sending the mentioned message). I have already used to have some strange problems in the past that where solved simply by reinstalling TAPI drivers. This time for some reason it is problematic for me to perform that once again and I am trying more analytical approach :). Any suggestions what might cause such a behavior? Maybe something on the other end of the ISDN line?
Based on your description, you are doing the playing asynchonously. Are you sure that the backing memory for the wav file is not being cleaned up in that time?
I don't have the time to Google too much for this, but I know that either Larry Osterman or Raymond Chen blogged about a similar situation.
I'll check back later when I have more time to see if this question is still open.
What is the return value when the sound does not play? If you get MMSYSERR_NOERROR that points to the driver incorrectly reporting to the OS that the buffer was processed.
Has the WAV file itself changed? This blog entry indicates that some pretty in-depth validation is done on the metadata.